Software defects are fixed easier when appropriate actions are taken as soon as the bug is spotted. Layers of additional code on top are making this task difficult and time-consuming. In fact, QA processes that take place later on after functionality is complete tend to toss businesses into deep pits of technical debt.
Why Continuous Integration (CI)?
Simply consider the following, one line of cold fix code costs about $3 and there might be thousands of defects in any system. Surely majority of those is of poor importance to both performance and business requirements, but any solution would operate better off without them, right? And such treatment of software development, when combined with poor decision on defect prioritization leaves many broken pieces of an app untouched thus opening doorways to usability issues, crashes ad hack attacks.
Luckily there are practices like Continuous Integration in existence that are designed to test and verify all changes that are taken within development thus delivering value of decent QA and spreading it throughout the entire project. CI is also a great tool for reporting current state of things to business owners thus granting better levels of assurance in product’s stability. Being sure every single feature works exactly as planned is a significant boost in planning and marketing activities.
Challenges of CI
Regardless of everything stated above CI is not perfect (unlike many believe). Otherwise other methodologies and development/QA practices would seize from existence by now, right? Continuous Integration processes still seem to be overfilled with challenges like:
- It’s hard as hell to actually ensure all of the product’s tests are run from accurate, fresh git clones or any other SCM checkouts. If you require accurate build results treat your CI server like one of juniors that are fresh in every possible aspect and this here is their first rodeo. Use appropriate scripts to educate your server about the application under development. Every single build needs to begin from clear definitions and must remain as independent as America itself.
- Standalone checkouts are a great solution for small and simple apps however growth in functionality may bring chaos to such a process. Such activities can only ne tended at the beginning of the process.
- Large teams tend to awkwardly operate CI. The more the merrier saying does not fit in Continuous Integration. Deploys are literally in danger when there are too many people involved. One nice practice is breaking the team into several sub-teams. New, additional roles should be given as well as responsibilities for sub-systems.
- Architecture over all! If architecture is poorly designed or proves to be a bit too complex it needs to be changed. Components need to fit together like pieces of a puzzle, not smashed closer with hammers. Component-Driven integration might seem like a great solution for software that needs to be rich on both feature and functionality.
- Repeatable and reliable tests are something few people can achieve. Failed tests are often treated as “expected” and intermittent failures cause sets of events that lead to mistreatment of legitimate errors.
- Instant and accurate feedback is constantly delivered to stakeholders and responsible managers. Thus requirements change more often than you might wish them to. Lots of code that is already created and powers sets of functionality and is already added inside the build becomes useless. Then changes are implemented and track of accurate, valid code is lost with remains of previous versions scattered all around the place. Preventing such confusion is easy – don’t break your sprints.
These are several examples of really deep flaws even something as great and promising as CI possesses and what does this mean in terms of QA? Never trust best practices and only use best fitting methods in your projects.