Skip to main content

The importance of continuous integration

Leading a team of developers in the effort of building a robust, quality software product should involve the establishment of some process and tools to assist the team effort and serve as a safety net for the errors of getting people to work together. Continuous integration is, I believe, a crucial element of that process. Introduced by Martin Fowler and Matt Foemmel (see article Continuous Integration), continuous integration establishes the practice of frequent integration of work developed by the several team members verified by automated build and testing of integrated code within a clean sandbox. This practice is valuable for several reasons:
  • It promotes the development of a clear process of building/deployment independent of any specificity of developer's platforms. Code that exists on a single platform only is bound to become dependent on specific aspects of that platform without anyone really noticing the dependencies until trying to port to other platforms. The existence of the integration clean sandbox allows these specific dependencies issues to not go unnoticed.
  • It promotes the development of testing. Being based on the premise of "test often" it makes the testing development part of the team's process. The fact that there is a platform built specifically for build and testing verification transforms, from the developer's perspective, testing efforts into an even more useful and justifiable effort.
  • It allows for quick detection of code integration issues by providing the clean slate for bringing all the code together. The little quirks of code combining can be detected by effective smoke/regression testing.
How hard is it to put in place continuous integration ? It depends a lot on where you are in your development process when you decide to take it up. If your team already makes use of build tools (e.g. Ant, Maven, even Make), makes use of a version control system (e.g. CVS, Subversion) and already does some kind of automated testing (e.g. xUnit) it can become pretty straightforward (You do use these don't you?!?). Continuous integration becomes simply a matter of setting up the integration sandbox and establishing the automation to detect changes in the version control system, building the changed system and testing the changes. You do not even need to go very far to accomplish that. You can find already systems that give you the continuous integration functionality that you need. At Tizra we have chosen to use the Cruise Control open-source, free framework for our continuous integration process (BSD-style license). It does pretty much what we need to do and keeps us on top of any integration issue that might arise from our development effort. It provides us unit tests results gathering, reporting and historical stats gathering for all checks. Continuous integration should be, in my opinion, an important practice for any serious software development company and I, for one, will make every effort to ensure it is put in place in every project I work with.

Comments

Popular posts from this blog

Free Webinar: How to get off the mult-format content treadmill

Free Webinar: Friday, September 21 12-12:30 pm (ET) How to wrangle ALL your content types into one beautiful online hub… and get off the treadmill for good! It never lets up. First it was publications and conference materials. Then blogs and social media. Then webinars, infographics, podcasts and online courses. You keep cranking them out, but where do they all go? How can you keep your communications investment from evaporating at the speed of Twitter? Tizra lets you bring it all together into a great-looking, searchable, mobile-friendly website that delivers long-lasting value to your audience. In 30 minutes you will learn... How to broadcast and curate mixed media types for maximum impact. How to categorize content for ease of use and maintenance. How a well-tuned search can reveal hidden gems. REGISTER NOW!

More Eggs in More Baskets: How the AWS Outage Made Us Stronger

Like a lot of web companies, we learned some hard lessons from the Amazon Web Services outage of a few weeks ago.   We didn't lose a single byte of data, but we resolved never again to put one service provider—no matter how large and diversified—in a position where its failure could cause a serious interruption in service for our customers. As promised, we 've now finished setting up automated data backup and redundant server infrastructure in facilities maintained by a completely separate company:  Softlayer Technologies .  Like AWS, Softlayer maintains the high security and reliability standards we require, including SAS 70 Type II Certification and PCI DSS Compliance.  And their Texas location adds geographic diversity to the Virginia and California regions Amazon gives us access to. This is in no way the end of our efforts to improve reliability and security.  We'll keep refining backup, failover and recovery processes to ensure not only that our customers' dat

Yum! Tizra Eats Its Dogfood

We keep talking about how Agile PDF makes it easy for nontechnical users to do sophisticated online publishing. Well, tell a story like that long enough and people start to wonder why you're not doing it yourself. Besides, any product benefits when its designers and builders are also users. Software developers call it eating your own dogfood . So a few nontechnical members of the Tizra team dug in (with Joya, pictured above, as menu advisor). We did it just they way any publisher would, applying our company branding with the Agile PDF control panel and basic CSS skills, then uploading PDFs . The only difference is we're not actually publishers, so we used files freely available on the web, and of course, we're giving them away rather than selling them. Voila! The New Agile PDF Demo Site Take a look . Then drop us a note , and we'll show how you can do the same—and a lot more—with your content. All of us, except maybe Joya, found it quite the best dogfood we