Author: Arad

Pipeline as code

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.

Write automated tests for your Terraform code

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.

Make your EF Query logs traceable

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
      select b).Take(10).ToList();

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!

Stop doing “DO NOT MERGE” pull requests

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.

Share your Azure Boards status with Status Badge

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.

Status Badge

Check “allow anonymous users to access this status badge” checkbox if you want to share your badge with anonymous users.

New “Basic” Process available in Azure Boards

Microsoft introduced a new process in Azure Boards called “Basic“. Now Azure DevOps supports four different templates to address different team size and projects with different needs and processes. New “Basic” process is very similar to github issue concept.

What does the world look like in Basic mode?

It’s all about simplicity. It just makes the process very simple and takes the heavy-planning-and-backlog-management bits out of the equation. If you are not maintaining an extensive multi-layer portfolio backlog where delivery must be tracked in different levels (and you probably have couple of cross functional teams), then “Basic” is for you.

You have a three-level hierarchy of ‘Epics”, “Issues” and “Tasks”. Technically speaking, everything is an Issue. If you are familiar with “Agile” or “Scrum” templates in Azure DevOps, an Issue is equivalent to a “User Story” or “Product Backlog Item (PBI)” or “Bug”. You’ve heard it right, there is no such a thing like Bug item. An issue is what you and your team need to deal with – it can be a bug investigation, bug fixing, feature development or a code improvement. You can breakdown an issue to some small tasks (this is usually done by developers) and then track your tasks as usual. Epic comes into the picture when you want to group couple of issues as a deliverable.

Is “Basic” for me?

First, lets’ look at the summary of all templates:

Agile:
This process is great if you want to use Agile methodologies to execute the project. You should choose Agile template if you want to track “User Stories” and “Bugs” on the Kanban board. This is recommended if you want to deliver a User Story from requirement gathering and design to coding, testing and deployment in one “iteration”. You manage your portfolio backlog through “Features” and “Epics” in this template.

Scrum:
Choose Scrum process if you want to use Scrum practices to plan and execute the project. Using Scrum template you can track “Product Backlog Items” and “Bugs” on the Kanban board. You manage and track your portfolio backlog through “Features” and “Epics”.

CMMI:
You should choose CMMI if you want to have auditable record of decisions and change requests. Using CMMI template you have to manage “Requirements” at backlog level and “Features” and “Epics” at portfolio backlog level. “Change Requests”, “Issues”, “Risks” and “Reviews” are other types of work item in this template.

Basic:
You should choose Basic if you don’t want to manage your portfolio backlog extensively and you see “Epic” as a deliverable. in this template you only have “Issues” to track your feature development and bugs.

Basic is a right fit for you if you are not into complex processes. It may not be scalable enough when it comes to big teams and complex plannings and executions. In both Scrum and Agile you can plot out complex delivery and feature road maps, while basic by nature is not really suitable for long-term multi-level planning where sometime you need to track the progress of a deliverable across couple of sprints or even (Hopefully not!) releases.

Bypass branch policy in Azure Repos

It’s a good practice to lock down your repo and put some branch policies in place to avoid merging unwanted codes and non-complaint branches and commits into your master branch. However, we’ve all been in that situation where something urgently needs a fix and for some reasons we can’t meet the branch policies. By using Azure Repos, you can give a special permission to a set of users to override and bypass branch policies when things are on fire.

Azure Repos allows your lead developers to bypass branch policies when they want to push code or complete a pull request when it’s needed. You just need to set the settings in your repo settings. Navigate to your repo’s security setting, select the group and role your super users belong to and set the bypass policies’s settings.

azure-repos-set-permission-to-bypass-branch-policies