Continuous Integration – a world of it’s own

I’ve been working with software integration for almost a decade and not so surprisingly Continuous Integration (CI) has been a part of that story. It all started with automating the builds. That is maybe simple task in some contexts but in my case we had the environment of hundreds of compilable products in multiple delivery tracks and an old school -waterfall- project world on top. And let’s not even go to the build environment itself, at least not yet.

So that was not the easiest ground to start with. Just a few guys with some sort of idea of the mysterious CI and still a lot of unknown things (mostly related to the whole test side and software flow). Things really started to roll once CI got high enough attention, or attention from high enough. Still it’s been a rocky path with a lot of things to connect, communication channels and networks to build and loads and loads of propaganda work. Things even happened so that in some point some other people in our organization came up with CI and it was not quite what we had been working with. So it’s been a long trip and required people from different roles to actually shape and implement the kind of CI that supports development of telecom products in large-scale distributed environment.

Let’s jump to the present, now we have the automated builds running, automated test on team level and on system level, continuous builds, daily builds, weekly builds, you name it it’s all there, almost everything you can come up with when reading the books,blogs and presentations. As stated the telecom (and other complex/regulated industries such as aerospace/defence) products may offer quite ‘nice’ challenges. So before jumping into any conclusion that daily builds and weekly builds are not Continuous Integration we should separate Continuous Integration as a developer practice and CI as a development practice.

In some cases the CI as developer practice is enough if the product and/or development ecosystem is suitable. Then again sometimes you also want to have CI as development practice, since continuous integration on large-scale and complex products is very hard to have only as a developer practice due to test lead times and test execution and test environment complexity.

This is now starting to dig a bit too deep for starters but stay tuned for more since we plan to chunk our experiences and views into a series of blog posts. Initially I though of starting this blogging stuff with some basic explanation of CI and the surroundings but then I changed my mind since others have already done that. Martin Fowler naturally gets the biggest credits on this with his now legendary definition of CI. I actually think It should be enough just to read his texts, understand the message and go CI big time. Or then you might want to study some other sources also and form your own view on this central practice of modern software development.


This entry was posted in Agile Thinking, All, CI, Continuous Integration and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s