Continuous Integration and Continuous Delivery (CI/CD) has advantages in small projects not just large projects
We had a client who needed us to take over the development and content management of a website. They needed to be able to review the changes and test the changes before the site was sent to their production enviroment. We saw this as a good time to start some new process improvements.
We suggested that we use a Continuous Integration (CI) and Continuous Delivery (CD) process. Continuous Integration (CI) is a process that requires developers to save their code into a shared repository, often. Every time a developer saves their code to a repository, an automated process is kicked off that can build and or test the code. This process detects problems early and often.
Continuous Delivery is an extension of the Continuous Integration process. The CD process deploys the code changes to a testing and or production environment after the build stage. This process, when done properly, assures that there is tested code ready to be released.
Here is our process:
- At the beginning of the sprint, create a release branch with version numbers off of the current “master” branch.
- Make changes to the release branch based on client needs. Commit changes often, just in case we need to revert/roll back any changes.
- Make sure the servers are up.
- Every once in a while we would merge the current release into the master branch by creating a Pull Request (PR). This allows another member of the team to review the changes and approve or decline the Pull Request.
- If the request is approved the source code is merged into the “master” branch. If the request is declined the author of the source code changes is notified and the reviewers notes are sent to the author. When the code is finally merged into “master” branch the build process is kicked off.
- If the build process is “successful” the source code is copied to the Azure web server. This is not our production server but our QA server. This is where we review the outcome of the compiled (build) code. Our client does not have access to this enviroment. This allows us to catch our own mistakes before the client see it.
- Before we can kick off any builds we need to make sure we turn our two web server instances “on”.
- Once we review the compiled code and approve the code internally we then “swap” the code in our QA server with the Production code. Yes I said swap. Swapping allows us to swap back if there is an issue, quickly. This process of swapping is called blue green deployment.
- We repeat this process as many times as need to get changes to the site completed. Once the client approves all the changes, we send the client the compiled code so they can put it on their server.
- Finally we need to send all the artifacts to the client. Once again inside of VSTS we can go into our builds and download the latest version of artifacts and send them to our client.
- Lastly we shut off the two web server instances in Azure when the client has approved everything. This allows us to save money on our hosting which is a big advantage of using a cloud service like Azure or Google or Amazon.
Every time the client has changes we start the entire process over again, starting with step 1: Create a new release branch.
