Continuous Integration for Agile Project Managers: Part III

Continuous Integration for Agile Project Managers: Part III (#3 in the series Continuous Integration for Agile Project Managers)
By Adam Leggett

In part 1 of this series, I hopefully provided you with an introduction to Continuous Integration (CI) and an overview of the building blocks of the CI process.

With part two, we introduced the concept of a CI life-cycle and how to bind software quality checks to discrete life-cycle ‘phases’.

In this final part, I’ll attempt to explain how you can use CI to run functional tests early in your development process and show how this helps us to promote a software release on its journey from development to production. I’ll then try to condense the three parts of this series into a handy diagram.

Automation, Automation, Automation

It should hopefully be clear by now that a successful CI implementation is largely dependent upon other processes that can be automated. For example:

• checkout or update of source code by a version control tool
• compilation of project source code by a build tool
• execution of source code checking by a static analysis tool
• unit test execution by a unit test harness or runner

Therefore, it seems reasonable that if we can automate a software development task in a way that is deterministic and repeatable then it can be executed during our CI process. The intention is to remove human error and have these tasks run in the background, and in the event of a ‘failure’ to be notified by a CI server. Some more advanced candidates for automation might include:

• provisioning of a clean, known harness or environment into which we deploy a release for the purposes of functional or acceptance testing
• starting and stopping services that are required for our functional tests and population of any test data dependencies
• execution of the functional tests

Functional Testing and CI

OK, so how do you go about adding these additional capabilities? Well, creating an automated suite of functional tests that can be triggered during the CI process is a reasonably non-trivial task.

Let’s take a look at the main areas for consideration.

Test Fixtures

In addition to writing the tests, you also need to carefully consider your test dependencies (also known as ‘fixtures’), such as any test data you might need in a database for example. Some code frameworks, like Ruby On Rails, encourage development teams to consider these test fixtures early-on in a software development project. Outside of such frameworks, it is more common to find ad-hoc processes. The key thing is ensure that your dependencies, such as a database, are in a known state prior to test execution and that the configuration or population of dependencies is entirely automated. Here, we can again apply the concept of a CI life-cycle to this particular scenario. We will need to bind the activity of test data population to a life-cycle phase prior to the execution of functional tests. We may also need to create a subsequent binding after test execution to ensure that we ‘tear-down’ the test data and keep everything in a known, consistent state.

Test Runner

Obviously, we require a tool that can execute functional tests in an automated fashion. Furthermore, there needs to be a way to trigger is execution at an appropriate stage in the CI process. Dependending upon the nature of the application you are developing, there are a number of choices¹. The majority of projects that I have worked on in recent times have been web-based, and we have used Selenium² extensively.

Selenium is open source, and allows you to test your app in multiple browsers. It also has bindings for lots of different programming languages, including a basic ‘dialect’ of HTML markup that is accessible to non-programmers (this type of thing is more formally referred to as a Domain Specific Language or DSL). It also comes with a browser plug-in that allows you to record and replay your tests.

Test Environment

The third piece in our jigsaw is the environment within or against which the functional tests will run. Environments are often overlooked where automation is concerned, but it is very common to experience issues during CI that are a result of an inconsistent or poorly-configured environment. In my opinion, you should consider environments as a ‘first class concept’. They should be treated like any other artefact of the development process – configuration managed, reproducible and ideally, verified or unit tested.

In addition, keeping the development environments in a form which mirrors a ‘cut-down’ copy of production really helps when promoting your application through the various test environments it may encounter on its journey into the live estate. Hopefully this should help you avoid the “Well, it works on my machine….” discussion that frequently happens in dev shops where environments are poorly controlled and managed.

If we have automated the ability to provision or script the creation and tear down of an environment, then should not surprise you that we can harness this within our CI life-cycle. For example, with enterprise Java (JEE) projects you can use tools such as Cargo³ that allow you to provision, start, deploy-to and stop your application server of choice. Cargo supports a wide variety of server environments, from open source, such as Apache Tomcat, through to Oracle WebLogic.

Wiring it Together

Ok. If you’ve been paying attention at the back throughout this series then hopefully the following diagram should make sense. Let’s recap the steps 1 through 12 below that represent the essential elements of a CI process that can help your agile project to deliver a high-quality solution. Note that at any point past stage 3, the build may be set to fail, resulting in an email (or other e.g. IM) notification to be sent to your team.

Continuous Integration – A Summary of Steps

1. Developers work to transform the requirements or stories into source code using the programming language of choice.
2. They periodically check-in (commit) their work into a version control system (VCS)
3. The CI server is polling the VCS for changes. It initiates the build process when it encounters a change. The build is executed using a dedicated tool for the job such as Maven, Ant or Rake etc. Depending upon the language used, the source code may need to be compiled.
4. Static analysis is performed on the source code, to ensure compliance with coding standards and to avoid common causes of bugs.
5. Automated unit tests are executed.
6. The percentage of the production code exercised by the unit tests is measured using a coverage analysis tool.
7. A binary artefact package is created. At this point we might want to assist derivation and provenence by including some additional metadata with the artefact e.g. a build timestamp, or the source code repository revision that was used to produce it.
8. Prepare for functional testing by setting up the test fixtures. For example, create the development database schema and populate it with some data.
9. Prepare for functional testing by provisioning a test environment and deploying the built artefact.
10. Functional tests are executed. Post-execution, tear down any fixtures or environment established in 8 and 9.
11. Generate reports to display the relevant metrics for the build. E.g. How many tests passed? What is the number and severity of coding standard violations?
12. The process is continuous of course! So rinse…and repeat….

¹ You can find a useful list of GUI testing tools here.
² Selenium can be found here extensively.
³ Cargo can be found here.

Adam Leggett has worked as a software consultant to UK FTSE 500 companies for over 10 years at UPCO. He specializes in enterprise technologies and agile Application Lifecycle Management (ALM) tooling. He is Chief Architect for Mike CI, providers of a simple to use, on-demand, hosted Continuous Integration service.

Mike – Smart Services for Smart Developers.