How we deliver the DevOps VSTS Bot

To deliver changes for the DevOps VSTS Bot into production, we use a combination of Github and Visual Studio Team Services (VSTS) to deploy a Web Application to Azure App Service.

Backlog

The team keeps the backlog in VSTS, using a Kanban flow, pulling work from right to left. As we are a small team and members are working on the bot in their free time, we do not want to force the team to adhere to an iteration cycle. But we have a weekly sync call to synchronize our efforts and we also report back every three weeks to other ALM | DevOps Rangers what our progress is.

Github

When a team member picks up work, they start coding on their own feature branch which are named based on the PBI id and the initials of the team member, then the code is pushed to Github. This way we see for who and for what a branch is.

When coding is done and the tests are satisfactory, a pull request is created to merge the code to our Development branch. When the pull request is approved, the initiator merges the pull request, which triggers a build.

When we are ready to ship an increment to the bot, we create a pull request, which merges the development branch into the master branch. The pull request needs to be approved by the ALM | DevOps Ranger’s Program Manager.

We intent to remove the Development branch in near future, to achieve a faster feedback cycle for our changes.

The DevOps VSTS Bot is an open source project, therefor we started directly from Github, so it open and available for the community to consume.

VSTS Build

A build is triggered when the code is merged within the development or master branch. Or when a pull request is created for the master branch.

The build makes a backup of the code, retrieves dependencies with nuget restore, compiles the code, runs our unit tests, runs a Code Analysis with Sonar Cloud and WhiteSource.

Backup of the code

With every build, the code is stored with the build. So in case of issues with Github, we always have a copy of the code as an artifact of the build.

Run Code Analysis with Sonar Cloud

Sonar Cloud helps the team, to keep track of their technical dept. The reports shows the team did not create any bugs, vulnerabilities, debt, code smells or duplicated code in the last 30 days, according to Sonar Cloud.

Nuget restore

As any other open source project, the bot consumes other open source initiatives. These dependencies needs to be downloaded from nuget.org.

Build solution

This is the moment the code is actually being compiled, but also the moment when the code analyzers are triggered and checks if we following the coding standards we set out for the team.

The build creates a package from the ASP.NET Web API Project.

Test Assemblies

The build also run our unit tests, we try to keep the code coverage above 80%.

Whitesource

We just added Vulnerability and license scanning to the our Continuous Integration. We still need to verify some of the dependencies, but it looks like we are doing fine. Just need to update a few dependencies.

Whitesource will also alert us, if there are vulnerabilities found in the dependencies in the future.

Canaries

Healthy builds are directly provided to the Canaries ring. We perform a few automated acceptance tests in the Canaries ring. Here the team and the Rangers tests the new changes before the package goes to the Users ring. This means a package is installed on as an Azure App Service.

Users

After approval from the Rangers Program Manager and the Project Lead, the package will be deployed into an Azure App Service. We currently are not using deployment slots, but we into use them, when the number of users pickup.