Ideally, software engineers are hired to write code that needs to be shipped to a production environment so that the business who needs the product can make use of it. To satisfy the business (often called users/clients), it is essential that the products are bug-free. The typical approach followed by software engineers is to work in branches and create a pull request which updates the master branch with the new update that has been made. We have adopted the practice of writing tests as a means of ensuring that the new changes do not introduce bugs. When developers work on a feature in most cases, they often do not create a pull request until they are completely done with the feature. What happens when they are ready is that;
They spend a lot of time trying to bring their codebase up to date with the changes that have occurred in the production branch while they were working.In doing that, they have to fix a series of merge conflicts.There is also the possibility of them breaking the production branch, which goes on to affect those who pull from the branch before the issue is seen and fixed.
If you have ever been in this situation, you’ll agree that it can be a pain – no one willingly likes to spend their workday like this. What’s the solution?
Continuous Integration
To prevent the scenarios I stated above; engineering teams can adopt the practice called continuous integration – as the name suggests, it involves the continuous integration of code changes made by developers into the shared branch/repository. The code to be integrated has to undergo a verified test to ensure it does not break the application. It is only when the test passes that it is integrated To understand this, let us imagine a real-life scenario where there is a team of 10 developers. These developers create a branch locally in which they write code for the implementation of certain features. Instead of sending pull requests when they are entirely done with the feature, they opt to send pull requests as they make little changes. An example of such change will be the creation of a new modal, assuming the developer is working on a feature that allows users to manage individual tasks in the application. Instead of waiting until the task feature is completed, to adhere to a continuous integration pattern, the developer pushes this little change (when compared to what she is working on) and creates a pull request to merge to the code. Before this new change is integrated, a series of tests have to run. Software engineering teams make use of tools like Travis CI to create these integration processes and tests. With tools like these, the tests are automated, such that it runs as soon as a pull request is submitted to the target branch selected during the setup. The results of the tests are generated, and the developer who created the pull requests can see the results and make necessary changes. The benefits of sticking to this pattern of integrating code as little as possible, and having a verified test to run are;
It becomes possible for the team involved to know what caused the build process or test to fail. This reduces the possibility of shipping a bug to production.If the team automates the process, they will have the luxury of time to focus on being productive.
The important thing to note in this practice is that it encourages the team to push code to the main branch frequently. Doing this will be ineffective if other members of the team are not pulling from the main branch to update their local repository.
Types of tests
In writing tests that will be part of the integration process, here are the some that can be implemented in the process:
Integration – it combines individual units of the software and tests them as a group.Unit – it tests for individual units or components of the software like methods or functions.UI – asserts that the software works well from the user’s perspective.Acceptance – tests that the software meets up to business requirements.
It’s important to note that you do not need to test all of these, as a handful of them may already be covered in the code written by the developer.
Continuous Integrations Tools
Without going into depth, here are tools that you can start making use of in your current or new projects;
Travis CI – known in the open-source world and promises to you have your code tested seamlessly in minutes.Circle CI – provides you with power, flexibility, and control to automate your pipeline from control to deployment.Jenkins – provides hundreds of plugins to support building, deploying, and automating any project.
Continuous Deployment
Of what good will it be if the feature you build sits in the repository for weeks or months before it is deployed to the production environment. As much as engineering teams can work towards integrating little changes into the main branch as it happens, they can also push these changes to the production environment as soon as possible. The objective when practicing continuous deployment is to get the changes made down to the users as soon as the developers integrate these changes in the main branch. Like in the case of continuous integration, when making use of continuous deployment, automated tests and checks are set up to ensure that the newly integrated changes are verified. The deployment only happens when these tests pass. For a team to benefit from the practice of continuous deployment, they need to have the following in place;
Automated testing is the essential backbone of all continuous engineering practices. In the case of continuous deployment, the code to be deployed has to meet up with the standard the team has put in place for what they intend to push out to end-users. Ideally, if a new change is below the threshold, the test should fail and not get integrated. Else, it becomes integrated.Despite having automated tests back-to-back, it is possible that some bugs will slip into the production environment. For this, it is needful that the team is able to undo a change that has been made – undo a deploy. This should revert the production code to what it was before the new change was made.Monitoring systems are needed to keep track of changes that have been pushed to the production environment. This is how the team can be able to track bugs that users encounter when making use of the deployed changes.
The tools mentioned for continuous integration also provides you with the functionality to set up a continuous deployment system. There are lots of them you can also read up on.
Conclusion
The productivity of a development team is vital to the success of the business. To ensure they are productive, practices that encourage this must be adopted. Continuous integration and deployment are examples of such practices. With continuous integration, teams can push as much code as possible daily. With this achieved, it becomes easy to deploy the newly added changes to the user as soon as possible. Deploying these changes makes it possible to obtain feedback from the users. In the end, the business will be able to innovate based on the feedback received, which is a win-win for everyone. You may also learn how to scale up and optimize CI/CD. If you are a developer and interested in learning CI/CD, then check out this brilliant course.
