More often than not, when teams are quizzed about adopting CI practices, a speedy reply would involve the name of some tool that drives the CI process within the software development team. Continuous integration is much more than a tool; it is a thought process that needs to be put to diligent practice.
Grady Booch proposed the concept of continuous integration in 1991. However, the idea of committing the code multiple times a day was promoted by extreme programming. Development teams are encouraged to adopt CI practices to avoid spinning out lengthy codes lounging on one's machine. When code merge takes place several times a day, it is practically impossible to test the whole application for every new line of code coming in. Though there is no explicit mention of test automation in CI practice, it is a derived understanding which development teams work on. Having the test automation in the CI process definitely helps to figure out the most probable failing introduced by new lines of code.
Tools assist us in our day-to-day activities. But, a deeper understanding of the CI concepts in its nativity will aid teams in utilizing the tool to its fullest potential. Let us discuss the perspective behind Continuous integration.
1.Encourage frequent Change:
The realization of continuous integration takes place during the commit action performed. Teams sitting over a convoy of code in their systems and finally realizing moving the code to repository one fine morning tearing apart the entire application is just not so ideal. Teams must commit the code at least once daily to avoid significant last-minute surprises.
The commit should also be propped with relevant tests to receive early feedback on changes entering the repository. Including Automated checks as part of this cycle helps arrest the manual intervention each time a new code knocks on the door. ACCELQ can be strategically integrated right at the commit stage to take advantage of frequent code changes and arrest bugs induced.
2.Early Feedback:
One of the most important thoughts that was put behind the Continuous Integration was achieving early feedback; what does that mean?. To understand it better, Let us recall previous development practices. The code was implemented and merged to the repository then testing was performed to identify the failures due to the new code. Teams had to work on the failing code and fix and repeat the action repeatedly.
When the code is just about to be committed it is checked for failures and stopping the commit in case of failures saves time and rework. The developer can continue working on his/her branch and recommit the code for another feedback loop. AccelQ does a great job in assisting teams in executing these tests early in the commit cycle and providing feedback. The ideal scenario for any development team is to ensure the test coverage for the application ACCELQ provides the test coverage metrics the details can be found here.
In case of commit failure, the notifications can be sent to the slack channel the integration to slack can be found here
SUGGESTED READ - What is Integration Testing? A Comprehensive Guide
3.Ownership & Accountability:
CI practice also encourages the code owner to take the entire responsibility for checking the code before committing. This means the code should be checked locally even before a commit trigger is pulled. The tests on the feature branch help to gain early confidence about commit results instead of committing the code and then waiting for the test results. ACCELQ provides an option to run the test scripts locally and grab the change feedback to make this step comfortable for the development team. How to achieve this? Find out more details here
4.Transparency:
Continuous integration promotes transparency, and every team member should be aware of the incoming code changes. It is of paramount to keep track of the changes for the version management and revert the code in case of extreme failures. The transparency is achieved predominantly by sending out notifications to all the group members. On commit, the test results can be notified through slack channels.
Transparency also applies to test coverage, the key for healthy application growth is to maintain healthy test coverage. During the continuous delivery mode, some features escape under the nose without any checks. ACCELQ provides the test coverage and traceability matrix to avoid such complications. It also provides a seamless experience to report any failures in the test execution by integrating with defect management tools. Find out more about this possibility here
5.Conflicts:
When multiple team members work on the same chunk of code, the chances of code overlay are quite expected. The concept of conflict management in the commit cycle is a wonderful thought process; the idea is to highlight the dispute between the incoming code. If two developers have changed the same piece of code, a qui vive is triggered right at the commit stage to decide which code should be moved ahead for the commit. Find out more about ACCELQ’s in-built version control capability here
6.Publication:
When tests are executed at the commit stage, the ideal practice is to include only those tests that are highest priority for the business. Why is that?. Because as the application grows, so do the tests. Executing all the tests at every commit takes an insane amount of time. Secondly, businesses are now taking the mobile-first approach. This means the code is primarily written for the mobile viewport, and then necessary changes are made for wider viewports. In such cases running X number of tests against Y number of viewports takes a crazy amount of time to complete execution.
The wise approach would be to induce only importance for every PR commit. At the end of the day, trigger a wide range of regression tests covering all browsers and devices to get overall test results of the changes introduced during the day; these are also called nightly builds. ACCELQ supports this practice by providing device farms that can be utilized for cross-browser and cross-device tests. ACCELQ is also well integrated with external device farms such as Browserstack, LambdaTest, and SauceLabs.
Final Thoughts
CI practice is not about the existence of a tool but about adopting its practices in the application development routine. Tools sure add value if teams understand which task and what practices to follow in what intensity and frequency. ACCELQ deeply supports development teams at all stages of CI practice. Starting from local test execution on the feature branch to testing the PR in the build pipeline, providing transparency through test coverage and triggering timely notifications for involved parties, and finally aggregating the test results to generate the execution history, ACCELQ has it all.
Sowmya Sridharamurthy
Sowmya Sridharamurthy is a seasoned product quality leader working as SDET Manager at Lytho. With 14+ years of experience handling products from inception to delivery, she has worked on diverse solutions- ERP, SAAS, Mobile Apps, and Web applications. She has a proven track record of successfully implementing result-driven test processes, non-disruptive migrations, and upgrades. Sowmya is driven to mentor development teams in building effective strategies and implementations to achieve ROI through test automation. Being an Accessibility advocate, she is keen on driving inclusive software development. Sowmya is an active community builder and runs an “APIans” meet-up group from Amsterdam."
