Name your yml file .vsts-ci.yml and put it in the root of your project.
What Does the Title Mean?
There is a lot of chat about build pipelines and continuous integration (CI) at the moment. For the uninitiated let’s break down the title of this post:
- CI = continuous integration, the practice of integrating ongoing development into your master development branch as soon as possible, making use of automated testing and building of your .app/.fob/.txt files
- Azure DevOps = Microsoft’s platform for hosting your development projects, track tasks, builds and releases (formerly called Visual Studio Team Services, formerly called Team Foundation Server)
- YAML = a markup language you can use to define the steps included in your automated build
This post isn’t an introduction to these concepts. You can find out more here:
- Freddy’s recent blog series on extension development – specifically part 3
- Session at NAVTechDays on CI/CD this year
- My own intro post on the subject
These days the cool kids are using .yml files to define the steps in their build. We’ve used the visual editor the define our pipelines in Azure DevOps for a while, but I think a .yml file is better, because:
- Your build definition becomes part of your source code, meaning you get version history, you can do code review on its changes and link changes to your build with corresponding changes to the source code
- Reusing the same pipeline across multiple Azure DevOps projects is easier – just copy the .yml file between the repositories
- Azure DevOps can automatically create the CI pipeline for you (finally he gets to the point of the post)
Automatically Creating the Pipeline
Simply name your YAML build definition file .vsts-ci.yml, put it in the root of the repository and push it to Azure DevOps. The platform will automatically create a new CI pipeline for the project, using the steps defined in the file and kick off the build.
This makes me pretty happy.
Credit to Abel Wang: https://www.youtube.com/watch?v=u3PNaLjTak4