At BizStream, we follow a development lifecycle (also called DevOps) that’s built to increase efficiency, provide continuous delivery, and improve software quality. Software deployments are only a small part of this overall lifecycle, but they’re the main focus of this blog post. First, I’ll briefly cover our development process from a high level so you can see where deployments fit into the big picture, and then we’ll dig into the technical details of deployments.
I’ll first lay out our development process from a very high level, starting with sprint planning using Agile and then ending with our deployment process.
First, I’ll start by discussing a development step that helps reduce the pain of deploying database changes. Database changes need to happen in a particular order, and it’s easy to make mistakes if the steps aren’t tested and performed carefully. The best way to handle database changes is with automation such as Entity Framework (EF) or Xperience by Kentico.
Version Control systems are essential to all automated deployment processes. They record all software changes made by developers and help us determine what code goes where and at what times by utilizing a branching strategy. At BizStream, we use the Git Flow branching strategy. Put simply, it’s a process that determines how finished code moves through the system before it gets merged into its final destination, the main code branch that is deployed to production servers at the end of an Agile sprint.
Gitflow can be used for projects that have scheduled release cycles, like most projects at BizStream, and for the DevOps best practice of continuous delivery. Gitflow assigns very specific roles to different branches and defines how and when they should interact (atlassian.com).
Here are the specific branches we use at BizStream and their roles:
In the past, we used a manual “copy and paste” process to perform deployments. We built the code on our local machine and copied the compiled code and web files over to the live server as fast as we could. Of course, we ran into issues, some changes were forgotten, deployments took up a lot of our time, and they were stressful. We don’t like taking our client’s sites down for extended periods of time either. So, we decided to automate these manual deployment steps using Azure DevOps and Octopus.
Build triggers are a signal to Azure DevOps to build the code in a specific repository branch. These are the same branches we discussed above in this article. At BizStream, we typically utilize the following branch build triggers:
So, what actually happens when a build is triggered? Here’s a list of our most used automated build steps:
The second thing we automated was our release process. We don’t want to pass around server credentials between each other, have developers logging into production sites late at night, or manually copying over files and database changes by hand anymore.
After the deployment package is created and sent to the staging directory by the automated build process, we utilize Azure DevOps or Octopus to automatically copy over the packaged code to specific servers. Below is a list of the most used steps in our automated release processes:
There isn’t a one-size-fits-all deployment solution that works for every team or project, but the deployment process outlined above usually works very well for us and our clients. If you’d like more information about the best DevOps and Continuous Integration practices, I highly recommend taking a look at the book Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim.
Stay up to date on what BizStream is doing and keep in the loop on the latest in marketing & technology.