Here are 6 steps to take your Development Testing activities (and more) from manual integration to Continuous Integration — all in less than a day.
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:
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.
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:
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.
Review your list and choose one item that if automated would noticeably improve your software development team’s productivity. Common selection methods include:
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
Look through your instruction manual from the last step, then:
The goal is to keep it simple and target the low-hanging fruit—you can worry about optimization, generalization, and parameterization later.
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.
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!
Jason Schadewald is a Product Manager at Parasoft.