Continuous Integration trigger – Azure Pipelines

Continuous Integration trigger – Azure Pipelines

Recently, I have received a proposal to create multiple repositories for a project. Of course, it could happen and really depends on the requirement(s) of the project.

However, after a series of questions, I realized that the reason was because the team is trying to ensure that only certain paths/folders are built based on the pushed files.

The rationale of doing that is to avoid unnecessary building of unrelated packages and that will help reduce the time required by the pipelines.

And that’s the short introduction about what brought to this post. A quick introduction about Azure Pipelines. It’s a tool assist with Continuous Integration and Continuous Delivery (CI/CD). It helps to automatically build, test, and deploy to the different environment to help smoothen and speed up the process of deployment without compromising quality/security of codes (Whitesource Belt and SonarCloud). For more information, you can refer to Microsoft Documentation .

For those that have used GitHub Actions or Jenkins, the concept is similar. When comparing the tools, the real benefits of using Azure Pipeline are the scalability of the agents and the Azure DevOps suite. For more information, you can refer to Microsoft Documentation .

Now back to the solution of the use case, it’s a simple trigger rule to be set for different pipelines. With a single repository, the team could build multiple pipelines with different trigger rules. It can be achieved using YAML file and/or UI.

For Pipeline 1: Picture1.png For Pipeline 2: Picture2.png The above is just a sample of the technicality for the trigger rules just for understanding purposes. For more example, you can refer to the reference from the Microsoft Documentation .

The above simple solutioning helps saved the introduction of complexity to the project.

Drop me a comment if you do encounter similar situation :)

With that, I wish everyone a Merry Christmas and Happy New Year!