Arad – Arad Haghi Personal Blog

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

CI/CD/CT at Enterprise Scale – Categorize Your Tests

moren-hsu-359121-unsplash — Photo by: moren hsu

When it comes to enterprise software, you usually have to deal with huge number of tests (I hope that’s the case for you!). One of the biggest challenges in having an efficient CI/CD/CT pipeline is to have a small set of tests to run to make the integration and deployment faster. One of the techniques to reduce the testing time is to limit the testing scope. I previously post a blog about Test Impact Analysis here which is one of the most reliable ways to trim the testing scope but also by categorizing your tests you can achieve small test surface even in development environment. Remember if you expect developers to run ten thousand tests before committing the code that will never happen!

Using TestCategory lets you create a group of tests using any arbitrary system you want (i.e. Domain, Scenarios etc.). This gives you an opportunity to create and run related tests together to facilitate the testing in CI/CD/CT pipeline. The only thing you need to do is to annotate your tests with TestCategory attribute.


[TestMethod]
[TestCategory("Aircraft")]
public void GetAllAircraft()

You can even assign a test to multiple category. If you want to filter your tests in Visual Studio by category you need to switch to list view in Test Explorer and then filter tests using Group By toggle.

CI/CD/CT at Enterprise Scale – Add label to Pull Requests

As a best practice, when we want to merge a topic or feature branch back into the main branch we create a pull request. Developers sometimes may need to communicate some extra information with reviewers or bring their attention to specific details. In VSTS, labels provide a new way of communication for pull request.

You can tag your pull requests with labels like “Hotfix” or “Dependency” or even “DON’T MERGE” and draw reviewer attention to an important details. Nowadays, many teams communicate things like this during the stand-ups or even through communication tools like Slack or Microsoft Team. However, when it comes to enterprise level app and big teams, traditional ways are not really practical because communications can easily get lost between team members.

CI/CD/CT at Enterprise Scale – Add Continuous Testing to Pull Requests

As a good practice we always branch out our feature branch from the main branch (E.g. master) and when we are done with the development, we send a pull request to merge changes back into the main branch.

Due to the fact that main branch always evolving and going ahead with changes from other branches, when it comes to merging back a feature branch to the main branch, changes could break the code. While we expect team members to update their feature branches with latest changes from the main branch before sending a pull request to reduce the risk of broken code, this is not working well at all the time.

This is why introducing continues testing into the pull request process removes the risk of broken code. This simply can be implemented in VSTS by adding a Build Validation as part of Branch Policies.

Navigate to list of branches, find your main branch and then select “Branch Policies”.

On the policies screen, click on Build Validations and add your build pipeline to the branch policies. Continuous test can be one of the steps in your build pipeline. You can make this policy Required or Optional.

You can also enable Test Impact Analysis (TIA) to reduce the testing and respectively building time.

You can fine more information about TIA here.

CI/CD/CT at Enterprise Scale – Enable Test Impact Analysis

As part of your CI/CD/CT pipeline you want to integrate, deploy and tests your application couple of times a day. When it comes to enterprise level application, we usually have a huge set of tests which makes it very hard and time consuming (if not impossible) to run every time as part of our continuous testing.

Test Impact Analysis (TIA) is a technique to determine the impacted tests for a given set of changes. Therefore, you don’t need to run all of the tests every time you want to build and deploy a new version.

TIA is just a click away in VSTS – you can easily enable TIA as part of your CI/CD/CT pipeline to dramatically reduce the time needed to run the tests.

You just need to enable “Run only impacted tests” in your version 2.* and above build’s test step.

Protect your Azure Backups with Multi-Factor authentication

You may ask why would you need to protect your Azure Backups – or precisely Recovery Services Vault with MFA? When you need to restore your backup, last thing you want to deal with is deleted backups [by hackers] in a rainy day for sure! So protect it or lose it!

To enable MFA on your Recovery Services Vault, Select your Vault, select Properties, Click on Update link under Security Settings and then set Multi-Factor Authentication to Yes and Save your changes.

Seeding data in EF Core 2.1

Microsoft announced Entity Framework Core 2.1 RC in Build 2018. Data Seeding probably is one of the most useful features of Entity Framework and it got a nice upgrade on this version. Unlike Entity Framework 6.0, Seeding data is associated with an entity type as part of the model configuration which means Entity Framework can now track added, updated or removed data from one change to another change and generates the corresponding migration script for the changes.

Seeding data in Entity Framework Core now is as easy as:

modelBuilder.Entity<Book>().HasData(new Book {BookId = 1, Title = "Don't read this book"});