During the past few years there has been a rise of interest in infrastructure-as-a-code. In my opinion, the rise of cloud computing was one of the biggest motivations and enablers behind infrastructure-as-a-code. Cloud computing was also an enabler for microservices. A typical microservice architecture requires many deployment pipelines which are for the most part identical. And this is a new challenge for many teams to deal with. Other emerging challenges are around version controlling and backing up build and deployment pipelines. From my experience and observation, cloning a build or deployment pipeline through CI/CD tool (if supported at all), and backing up the build machine are the most common answers to address above challenges. While these techniques may help to address some of the concerns, but they are not perfect and scalable. You might be able to clone pipelines as many times as you want manually through your CI/CD tools, but can you apply a change across all the pipelines in one go? If you need to manually change each pipeline to accommodate new changes, then you are in trouble. If you have no history or version control around pipeline changes then you better to pay your DevOps engineer well and make sure he is not leaving your company! Do you backup your build machine after any change into the pipeline? Do you health check your backups? What do you do if you don’t have access to a build machine? These should be enough to prove you need a better and easier way to maintain your pipeline specially when it comes to microservices, enterprise application and scalability. The answer is simple – Pipeline as Code; Similar to Infrastructure-as-a-Code concept. Pipelines as code is defining the build and deployment pipelines through code instead of configuring a running CI/CD tool. So now, if someone forks or clone your repo, they can get your pipeline definition as well as your code. Jenkins, Azure DevOps, LambdaCD, GoCD and Drone are some of the major players when it comes to pipeline as code. Microsoft introduced build pipeline as code for Azure DevOps in Nov 2017; However, release pipeline still in progress and not fully supported at this stage. If you are not doing pipeline as code, I believe you need to start doing it from today and version control all the changes.
If you want to know A – Z about Jenkins pipeline, I recommend you to watch this training.
When it comes to Azure, I always prefer to implement infrastructure-as-a-code through ARM template than Terraform, but that is not always a choice; It is called life. Love it or not, sometimes you need to implement your infrastructure-as-a-code with Terraform and believe me or not, maintaining a large codebase of Terraform is not the most interesting job in the world. Introducing a change in a infrastructure-as-a-code’s code is always error prone and hard to test. Well, it shouldn’t be. Terratest helps you to write automated tests for your Terraform code. A Go Library which helps you to test your Terraform code, Packer templates and Docker images.
The good news is, starting with Terratest is simple and straightforward. You just need to Install Go first (This was the hardest part for me to convince myself to install Go 🙂 ), and then you just need to add Terratest to your project through one of the Go dependency manager such as dep.
dep ensure -add github.com/gruntwork-io/terratest
You are all setup now. You just need to write your tests using Go’s built-in package testing and then use Terratest to execute your Terraform code to deploy the infrastructure to your environment; And then, use Terratest tools to validate your infrastructure (E.g. Making HTTP or API calls). When you finished with your testings you simply need to tear down the environment.
This way you simply can apply changes to your Terraform code with confidence.
If you are a .NET developer, there is high chance that you’ve spent way too much time looking at Entity Framework logs to understand and investigate generated queries. Probably one of the most time-consuming tasks is to find out what has been translated to what especially when it comes to complex chatty solutions. Entity Framework Core 2.2 introduced a new feature called Query Tags which can be used to tag queries and make the output traceable. You simply can annotate your LINQ queries using TagWith() method.
Let’s have a look at an example. In the following example, I annotated my query with “List of top 10 books”:
var books =
(from b in DbContext.Books.TagWith(@"List of top 10 books")
orderby b.Price descending
And here is the query output in the the log:
-- List of top 10 books
SELECT TOP(@__p_1) [b].[Id], [b].[Name], [b].[Price]
FROM [Books] AS [b]
ORDER BY [b].[Price] DESC
Now as a developer, I can easily find out my query output in logs without burning calories!
You probably have been in a situation where you finished your task and ready to create a pull request, but for whatever reason you don’t want your changes to get through (For example, you want to merge your changes back into the main branch after the current release). A common behavior – or let’s say old fashioned way – is to put something like “DO NOT MERGE” or “WORK IN PROGRESS” in the pull request’s title. And as an unwritten rule you should write it in all caps :). In such a situation, you can draft a pull request instead of creating a pull request.
To Draft a Pull Request in Azure Repos, you need to choose “Create as draft” when you want to create a pull request.
If you look at the list of pull requests now, you will see your pull request marked with “Draft” token.
Microsoft introduced a new feature in Azure Boards called “Status Badge” which summaries your board status in a git-style badge and allows you to share it in your docs and dashboards.
You can find this new feature in your board settings under Status Badge.
Check “allow anonymous users to access this status badge” checkbox if you want to share your badge with anonymous users.