6 Steps to Continuous Integration for Development Testing

In the most creative and advanced companies, Continuous Integration extends far beyond build automation, enabling teams to achieve greater scalability, productivity, and quality throughout the SDLC.

Here are 6 steps to take your Development Testing activities (and more) from manual integration to Continuous Integration — all in less than a day.

1. Identify Manual Processes

Start off by taking an inventory of your regular time-consuming efforts. Your goal is to identify tedious “must do” tasks that you or your team performs over and over. The processes you identify may include:

• Transferring files between machines
• Entering commands in a console
• Copying data between different systems or into another format
• Visually verifying information, data, or test results
• Writing documentation
• Getting verbal or written approval
• Scheduling and participating in meetings
• Clicking a button/icon to execute a script or program
• Creating and sending reports

At this stage, you don’t need to worry about automation; focus on determining tedious, routine manual processes. If creating this list takes longer than 15 minutes, stop where you are and move to step two.

2. Estimate Frequency and Duration

Now that you’ve created a short list of these processes, your next step is to determine the relative gains from automation. The easiest way to do this is by estimating frequency and duration. When estimating the frequency of a process, don’t limit yourself to current conditions. Instead, focus on the value of the process by considering how often you would use the results or how long it takes before the results become outdated:

• Several times per day
• A few times per week
• Every sprint
• Twice per release cycle

Next, go through the list and estimate how long it takes to complete each process under current conditions. Durations can range from minutes to days for common process. It’s a natural human tendency to underestimate durations, so feel free to round up or add fudge factors.

3. Select (Sub) Processes for Automation

Review your list and choose one item that if automated would noticeably improve your software development team’s productivity. Common selection methods include:

• Choose the process with the highest duration
• Choose the process with the highest frequency
• Choose the process with the highest (frequency) * (duration)

At this point, many people make the mistake of taking an “all or nothing” view. Instead, focus on the portions of the process that can be automated and proceed with the understanding that you will improve as you go.

Go through the exercise of doing the task, either mentally or physically, and make notes for each step. Jot down information gathered, commands entered, permissions needed, people involved, etc. – enough to jog your memory later.

The end result will be a mini instruction manual for a repeatable human process. Review your instructions and identify the steps that a computer can perform. Commands you entered into a console or textbox and any information pulled from a website or database are good candidates. For multi-person and multi-stage processes, also pay attention to methods of notifying individuals of their turn and role in the process

4. Create Automation Scripts

Look through your instruction manual from the last step, then:

• Copy your console commands into an editor and save them as .bat (Windows) or .sh (Unix/Linux) scripts
• Use a development testing tool with a command line interface to
  • Statically analyze code for safety, security, and defects
  • Automatically generate and run unit tests
  • Automatically assign and track peer review tasks
  • Functionally test APIs
  • Scrape websites, services, and databases for intermediate data
• Use build and reporting tools to inform subsequent stages of the automation infrastructure
• Capture multi-stage processes in the form of BPEL or another high-level process engine

The goal is to keep it simple and target the low-hanging fruit—you can worry about optimization, generalization, and parameterization later.

5. Schedule and/or Trigger the Artifacts

The formally-accepted definition of continuous integration specifies that your script must be triggered by a commit to your SCM. Most people, however, really just care about getting work done. Whether their processes match one definition or another is beside the point. Feel free to carve out your own interpretation of CI that saves you the hassle of tedious tasks.

Now that you have a script or other automatable artifact, you need a tool to manage the scheduling/triggering of those artifacts. One straightforward strategy for finding automation tools is to search for the term continuous integration; the results will yield tips on automating not just the build, but scores of other development, QA, and IT activities. CI tools provide the simple and necessary framework for scheduling the regular runs of some artifacts and stitching together the triggered runs of others.

6. Iterate, Improve, Repeat

With the time you saved automating your Development Testing processes, you can now focus on improving your basic continuous integration implementation. Go back to step one and add some new manual tasks to your list. For example, maybe you manually modify certain scripts or copy them for slightly similar purposes. Your next automation project might be to consolidate and parameterize your automation artifacts

You just jumped 2-3 CMMI levels (for those keeping score). Congrats!