CI/CD with VSTS
Builds
- Set up Git – create a remote.
- Push existing code or pull code from VSTS.
- Create a “Build and Release” definition (New Pipeline). Beware: you must be a member of Build Administrators group or some other group that has Edit Build Definition permission set to True. Ask project owner to make you the admin and you can add yourself as the member.
- Choose a template.
- Build from master.
- Now you are at “Tasks” tab. This is a list of dotnet commands to be executed.
- Change default name, make it descriptive: “PwHelloAzure-master-CI”.
- Click “Build Process” on the left side.
- Agent Queue: “Hosted VS2017”.
- Somewhere in the cloud there is a machine with VS2017 being used to build our project.
- We can also build on a private build agent, but this requires us installing some software on our machines.
- “Get sources” is repository settings (already set at this point) and build tasks.
- Each task might reference some variables. Variables are of the format $(variable_name), e.g. $(BuildConfiguration), $(build.artifactstagingdirectory).
- You can define the variables in the next tab: “Variables” (some are already predefined, some are editable).
- “Publish” task: look at the command. It outputs the result of build into the $(build.artifactstagingdirectory). Default directory name is “drop”.
- “Publish Artifact” – publishes what is in $(build.artifactstagingdirectory). You can download and install this locally as well.
- “Triggers” tab.
- “Enable Continuous Integration”
- Include master – when something is changed on master branch (push into or a pull request merge), start build.
- Other options:
- “Scheduled” – you can set a fixed time of day to trigger the build and release.
- “Build completion” – start another build after this one has finished.
- “Save and Queue” -> overview -> “Save and Queue”
View Builds
- Menu: “Builds and Release” -> “Builds” -> hover over build -> ellipsis
- Several options appear in the popup:
- “View build results” – you can see build server console output as it is being built.
- “Edit” – open build task details, you can reconfigure stuff here.
- Several options appear in the popup:
- You can check each build and each step within the build.
- “Logs” -> ellipsis -> “Download all logs”.
- “Artifacts” -> “drop” allows you to download the built application.
Releases
- brief overview: we must determine what it is we are releasing. Then we determine when we want to release. After that we define where we want to release.
- Menu: Releases -> New Pipeline -> Azure App Service Deployments
- Name it: “PwHelloAzure-CD”
- Define an artifact. This is the built code you wish to deploy. Choose the build pipeline you defined earlier. It will also say what is the name of the last artifact built by that pipeline (default name: “drop”).
- Once an artifact is defined, click on the lightning bolt next to the artifact: “Continuous deployment trigger”. Here you can define when you want to trigger the deployment. You can also deploy on a certain schedule.
- Environments – here you define where you want to deploy: staging, QA, load testing, production.
- To the left of the enviroment, click on to define Pre-deployment conditions. These are additional filters per environment, e.g. : only after a release, manually, deployment must be explicitly approved by someone, etc…
- Tasks allow you to define concrete steps to be taken on deployment:
- Task #1: Connect VSTS with Azure and define deploying to Azure. You need to be a member of Release management group to create a new Azure connection.
- Run on Agent – allows you to define where the step will be run. This is the same as for builds: Hosted VS2017. Nothing to add here.
- “Deploy Azure App Services” – define where exactly to deploy:
- Deploy to slot: staging.
- Leave rest at default.
- Task #2: Slot swap. Find the task and add it to task list. Define it (options are intuitive).