The calm summer months are the perfect time to work on some long intended, internal projects. This month, we finally found the time to fully automate our web deployment using VSTS Release Management. In this blog post we share our release process and its technical implementation using VSTS and Azure.
Background
Following the DevOps principles, we try to automate as many routine processes as possible. Automation has lots of advantages. Here are some examples:
- It frees resources because nobody has to waste time with boring routine tasks.
- It raises quality because human errors are large ruled out.
- It makes processes consistently repeatable.
- It enables doing important things (e.g. tests) more often.
- With proper logging, processes become traceable.
- It makes processes more independent of certain people. Vacations or sick leaves don't stop processes to function.
We have been doing build and test automation for years. Yet, our release processes still needed some manual work - until this month. This month, we used a relatively calm summer month to work on fully automating our release pipeline.
Business Process
At the beginning of this year, we changed our release schedule. You can read more details in our blog post Change to Our Release Cycle. To make a long story short: We maintain three public environments:
- Dev: Latest bits coming from continuous integration process.
- Preview: Release candidate beween 1st and 10th of each month.
- Production
The following image from the previously mentioned blog post illustrates our release cycle:
Input for Release Management
Most of our important components are built in the cloud using Visual Studio Continuous Integration (CI). The result of the automated build is the input for release management.
We use cloud-based PaaS and SaaS for our internal systems wherever possible to free our team from having to install and maintain base components like operating systems, databases, build servers, etc.
As a result, we decided to run our builds on Microsoft's hosted build agents. Here is a screenshot showing a build history from a typical time cockpit component:
Input for Release Management
Whenever a CI (=build + tests) process finishes, it creates a new release. The release is automatically deployed to our Dev environment. Deployments to Preview and Production require confirmation by an employee.
Releases
The following screenshot shows the release status of the last few days. Note the selected version 2017.08. This is the new production version we deployed today. The older releases were releases we created for testing purposes during the month. They have just been deployed to Dev and Preview. You might wonder what the forth environment is. It is related to our nuget Feed on myget.org. I will not go into details on this in this blog post.
Here is the history of the latest version that we pushed to Production:
Deployment
What does it take to deploy a version to different stages? As mentioned before, Dev is published automatically after a success CI. The push of new releases to other environments is just one click away:
Conclusion, Next Steps
Our new automation of releasing time cockpit has already proven to be a great time saver. Our goal for the next months is to get rid of the last on-premise, TFS-based pieces in our CI/CD infrastructure. Given the small size of our team (we are just five technical people) and the level of professionalism (SLAs, data security, redundancy, etc.) that we aim for, cloud-based PaaS is the only feasible option for us. It frees us from boring routine tasks and lets us focus on delivering value to our customers.
comments powered by 