Continuous Integration: Instilling Quality Early & Often
As strategic business visions continue to push the boundaries on technology solutions, the need for a real-time approach to quality has become increasingly important. With the transition from waterfall to agile, engineering teams went from multi-month, milestone release schedules, to 2-4 week tactical sprints; bringing visibility and exposure to demonstrable functionality. This shift has caused teams to re-think the way they approach quality and as a result, the practice of continuous integration (CI) was born.
As CI best practices have evolved, the idea behind continuous integration has changed the way teams practice Build Management, Release Management, Deployment Automation, and Test Orchestration. By establishing an automated approach to quality throughout the development life-cycle, teams can streamline the feedback loop and save time (read $$$) debugging dependent code issues and compounding technical debt.
Now that you understand the importance and the goals behind CI, let’s explore a few tools and tips to implement this into your organization:
- Bamboo (Atlassian) – After having worked with the Atlassian suite for two projects now I have seen first hand how much time and effort the team at Atlassian has put into building their entire eco-system of products, especially JIRA & Bamboo. From multi-stage build, deployment, and executions of automated test scripts, the Bamboo tool does a fantastic job of bringing visibility to where quality issues exist throughout the development life-cycle.
- Hudson - Built and maintained by the Eclipse Foundation, Hudson has the capabilities to build and test software projects continuously while at the same time monitoring executions of externally run jobs.
- CruiseControl - CruiseControl is both a CI tool and an extensible framework for creating a custom continuous build process. It includes dozens of plugins for a variety of source controls, build technologies, and notifications schemes including email and instant messaging. A web interface provides details of the current and previous builds. And the standard CruiseControl distribution is augmented through a rich selection of 3rd Party Tools.
- Quality is everyone’s job: One of the popular misconceptions is that QA is the sole responsibility of the QA team (FALSE). The quality process begins when the team (Product Owner, BSA’s, Dev, QA, etc.) agrees to their definition of done (the criteria that must be satisfied with each user story to call it complete). One methodology that I have used with my clients is BDD (behavior driven development). As the Product Owner communicates the business vision and roadmap into epics and user stories, the BSA’s should structure their acceptance criteria into Given, When, Then statements. (I.e. Given the customer is on the home page, when the customer clicks on the login icon, then a login form will appear.). These statements formalize the functionality that is trying to be achieved in the user story and should be used by the engineering teams as comments that are embedded within the unit tests, automation scripts, and source code.
- Automate from day one: By automating your test scripts from day one you can build up a regression suite that can be executed throughout each sprint and which contains all of the prior functionality that has been accepted from previous sprints. This will prove to be very useful during “hotfix” releases.
- Focus automation execution on a limited set of browser/OS combinations: Each browser and OS combination can introduce new variables into your testing environment and it is important to focus your infrastructure build out on a limited set of combinations. Remember the goal of CI is to prove functionality works, not necessarily UI defects across browsers (this is a good task for manual exploratory testing).
Additional Details, Best Practices, & Thoughts: