Blog

How Continuous Integration Helps Us Keep Projects Moving

Feedback Loop How Continuous Integration Helps Us Keep Projects Moving

By Dennis Portello

One of the differentiators of good interactive technology & development firms is process. Not smoke and mirror strategy mumbo-jumbo but the process through which innovative thinking is actually executed and delivered. It does not matter how great an idea is, or how good it looks, if it doesn’t work … it’s shite.

At Zemoga, we pride ourselves on being able to deliver on the promise that innovation often reveals to us. How do we do that? We make sure that we follow the best practices out there. We learn from mistakes others make, and our own. We constantly improve. Perfection is not a destination but a journey nobody ever really completes. Just ask Tiger.

post-image

By Dennis Portello

One of the differentiators of good interactive technology & development firms is process. Not smoke and mirror strategy mumbo-jumbo but the process through which innovative thinking is actually executed and delivered. It does not matter how great an idea is, or how good it looks, if it doesn’t work … it’s shite.

At Zemoga, we pride ourselves on being able to deliver on the promise that innovation often reveals to us. How do we do that? We make sure that we follow the best practices out there. We learn from mistakes others make, and our own. We constantly improve. Perfection is not a destination but a journey nobody ever really completes. Just ask Tiger.

So then, how do you keep a large interactive project moving at full-steam ahead over time? How do you make sure that your ducks are in a row so that your client can dine on Confit? On the surface, most projects appear to be driven by new development and deliverables. But on the contrary, as the project progresses, the burden of integrating existing features and testing often easily surpasses the  generation of new features.

The magic potion for many world class development firms like Zemoga?

“Continuous Integration” (CI) is a methodology based around a series of tools and best practices that helps a project maintain bullet-train momentum, without getting derailed by time-consuming integration issues and regression bugs. You techies know what we mean.

To achieve this state of development nirvana,(see above ref. perfection) a dev team should embrace“Test-Driven-Development” (TDD). This involves a developer digesting the requirements and writing a series of tests around them before they actually write a line of code. As the code is developed, the tests will most likely fail, as will other tests written previously. Once the tests all pass, it’s time to check-in the work as a group of related changes called a change-set.

At this stage, it’s important to have an automated build process that builds the project and executes a battery of tests. Not only does build automation save time, but it also guarantees that deliverables are created in the exact manner each time. These scripts should execute quickly so each member of the team is more inclined to run them manually from the command line or in their “Integrated Development Environment” (IDE) when they add their own contributions to the project.

If you are sticking with me on this….now it’s time for the CI server check out the change-sets, build the project and run the test suite. If for any reason the status of the project changes due to compilation errors, or exceptions in the test suite, the last person to check-in their change set is blamed. Most of the time, this is due to a missed file in the change set, but it could also be due to an integration issue, which would’ve been avoided by taking updates from the repository and testing before submitting their own changes. In the worst case, someone was careless and didn’t run the test battery before submitting the change-set to make sure there weren’t integration issues.

Regardless, if a developer broke the build, they were most likely not adhering to the designated, agreed-upon process. Now a penalty is in order or at least a hard cross check! At least it is caught early. Battery cables are not the prescription, but 25 push-ups in front of the team are!

As part of the CI process, other sorts of checks and analysis tools could be plugged-in as well. Aside from the test battery, it’s also important to see how much of the code base is covered by tests. Plus, there are tools for ensuring the code adheres to style guidelines, keeping the complexity low, avoiding duplication, and much more. This all translates into efficiencies that are noticeable to both schedule and client.

The point is, with a good CI process in place major issues never see the light of day on production system, and most issues should never even make it to QA. They will thank you later. The QA team should only spend their valuable time verifying the agreed requirements set, and not reject builds on grounds that they’re not production worthy. That’s our job.

Get in touch with us

let’s start building better today

Contact Us