- On February 24, 2018
First Steps in CI/CD
The introduction of continuous integration and continuous development into DevOps has significantly impacted the way developers and testers alike ship software. Considering how complicated it is to develop and release a software that’s bug-free, CI/CD allow developers to review their code on a faster and more consistent pace.
With a proper CI/CD environment, you can create new experimental features, make appropriate changes, and implement new updates quickly. The question is, how?
Learning the Basics
To learn the steps, we need to learn the differences first.
Continuous integration is a development practice that involves testing minor adjustments in a software’s underlying codes each time a developer pushes updates. The purpose of CI is to hasten the release process by allowing developers to search and fix bugs earlier while still in the development phase.
Before CI, developers used to work on separate parts of an application and later integrate their codes with those from others manually. This proved to be time-consuming and a bit unreliable since (1) it may take days or even weeks to integrate the codes and (2) it will be harder to find and fix any bugs that might be present. With CI, developers can just merge their codes in a shared repository so they can be tested and validated simultaneously for several times a day.
Continuous delivery, on the other hand, involves pushing new updates to users as soon as possible. It naturally follows right after CI and is used for reducing the risks that might be associated with the release of a software and its new features. This is possible by making sure that every change being made to the application’s codes is smaller and deliverable to users on a frequent basis. Doing so allows developers to process more safely and efficiently; not to mention they can get almost immediate feedback from their users.
While there’s no standard structure for CI/CD pipeline, it’s often broken down into three main stages:
- Commit and Build – after making appropriate changes, developers will commit their codes into a shared repository. They are then integrated into the central code base. The software or new update is then formed from the codes extracted from the repository. CI actually plays a huge role since it automates each step after writing the code.
- Automated Testing – following software development, it should then be built and tested to make sure it can comply with the initial requirements. In this stage, you have to test your entire system in the same environment that your end users can access because it will greatly affect its success rate.
- Deployment – this is basically the final step. The software then goes into production. This is where CD plays its main role by automating the process and ensuring continuous and reliable delivery to users.
First Steps in Continuous Integration
Now let’s move on to the initial steps involved in Continuous Integration. They are as follows:
- First, you have to use a version management tool such as Subversion or Git. Most developers tend to use the repository as a backup and add files like movies or photos into it. Don’t do that. It should be kept clean as possible. Make sure you only include configuration files and source codes into it.
- Second, plan your development strategy. During this process, you need to come up with a development strategy that everyone in the team can accept and understand. Not doing so will only cause conflicts due to poor communication and information relay.
- Plan your delivery strategy depending on what you plan to develop. The delivery is typically the end part of the development pipeline. In this case, you will need Continuous Delivery especially if you’re developing a software. Your delivered result could either be a software installer which you can deliver to your end users. It’s not just limited to softdev, however; it can also be applied to web development in the form of updates in the production environment.
- Next is to plan your application version strategy. Your app’s version will reflect the changes you made and inform your end users about those changes. In large-scale projects, an app’s version number can include three or four digits. For example, a software with a 2.5.132 version can mean:
- 2 for the software’s base version (this means version 3 will be a complete rebuild)
- 5 for the marketing version used to announce new updates and features
- 132 for the revision number to indicate every change made in the repository
- Afterward, you need to use a build automation tool. This tool monitors the status of every build step. If all of them are successful, that would mean a potentially releasable application. You can use a number of build automation tools such as Phing, Ant, and more.
- Perform unit testing by independently testing your methods and classes. You can use MSTest and other similar programs to do so.
- Create a test environment using your software’s latest version. This is important to make sure that everything is working perfectly. To create such environment, you need to include external content, compile and build the most recent source code, then configure your environment. Once you’re done, you should be able to create a test-ready environment.
- This is where the testing phase commences. During testing, you have to make sure that all of your software’s functionalities are tested. However, you can’t test everything, so focus only on the most important features of your software. Implement a “Happy Flow” which is virtually a path that a user will most likely take by picking the right options. You should also perform functional testing in a parallel way. This will allow you to reduce build time significantly.
- In the event your testing is a failure, you have to gather feedback so you can debug errors as soon as possible. It’s recommended to take screenshots of those bugs and create an error log to make debugging a lot easier. The build automation tool also helps a lot through its notification systems to inform your team whether your build succeeded or not.
- Lastly, don’t forget to back up your build automation. Make sure you save your logs and configurations. Also, if you’re using the tool on Windows, it’s important to install a virus scanner.
First Steps in Continuous Delivery
Let’s move on to Continuous Delivery. Due to the high risks of bugs and unreliable codes involved in large-scale software releases, CD is often broken down into smaller but more frequent releases. This is how a typical CD pipeline goes:
- Start with build automation. If your team practices test-driven development (TDD), you’ll have to create unit tests for every code written before the actual writing begins. Developers will have to invoke the compiler manually. With a build automation, the build is automatically created.
- Next, in Continuous Integration, you will have to check the code into your shared repository a few times per day. The automated build will verify each check-in, thereby allowing you to spot any conflicts and errors as quickly as possible.
- Continuous testing is important, especially if you’re integrating codes to your shared repository a few times per day. We all can agree that manual testing is very time-consuming, not to mention too complicated. With test automation, you can simplify things. While there are no definitive rules about which tests to automate, when, or if they really need automation or manual testing, automated tests are often favored by a number of Agile testing experts due to their higher ROI.
- Lastly, we have deployment automation. As the final step in the CD pipeline, a software then proceeds to production after passing all tests. This means releasing every stable build to your end users. The good thing about deployment automation is that you can quickly deliver every new change or feature to your end users whenever necessary. Moreover, it also allows your DevOps team to receive feedback, which in turn will help you fix any possible issues or respond to your users’ requests.
The problem with deployment automation is that it can cause downtime due to the release of an application that isn’t production-ready. However, DevOps teams often resort to using several deployment strategies in their pipeline to achieve zero downtime. These include “blue-green deployment” and “canary releasing”.
- The blue-green deployment includes the setup of your software’s latest version into your product application stack’s clone. This is followed by the switching of traffic from your current stack towards the new one once your software successfully passes all tests in the pipeline.
- Canary releasing, on the other hand, is a reference to the method used by early-day miners which involved releasing caged birds into the mine tunnels to confirm is the air is safe for breathing or not. Applied to development, this includes releasing your software’s next version into production, except that you’re only limiting it to a small portion of your end users. Once it successfully passes all environmental tests, you then start releasing it to a wider audience.
The very first step towards a highly successful CI/CD pipeline is choosing the right tools. You can’t use just about any tool for your DevOps team and expect to see successful results. Each tool is different, especially when it comes to features. Also, some tools are intended for specific purposes, such as Ant for automatic software build creation, Jenkins for project automation, Artifactory for managing your repository, and a whole lot more.