These days, Continuous Integration is a buzzword in technology and it has almost become the normal method of implementation for a lot of companies. But to some, Continuous Integration, or CI as it is often called, is still something new and scary. However, it absolutely doesn’t have to be, so here is a brief introduction to get you started.
Don’t you wish you could get faster feedback on your builds? Wouldn’t it be nice if none of the builds given to you for testing were broken, or missing a key component that was left out by mistake? Maybe you’re more concerned about finding out if merging your branch back into source control caused any major problems or testing blockers?
This is where CI comes into play! Effectively, CI is there to save time, whether for QA, Development or Operations, whilst simultaneously increasing overall confidence in your quality.
CI systems don’t actually make code builds, they don’t branch code, and they don’t execute tests. Your CI system is an integration layer that helps you pull together the disparate systems, tasks, and needs into one central source. It schedules the tasks, regardless of the system that they come from, and then it aggregates the results of your tasks and presents them in a useful manner. They generally have a form of GUI that allows you to schedule things and review results, in addition to possessing some capability to have things kicked off from other systems and send reports; either directly through email, or to another aggregating or monitoring service.
CI pipelines are often used in development settings in order to execute a series of tests immediately after the developers make a check-in to source control. This is a very efficient way to run Smoke Tests on all your builds, or to verify that the latest code check-in didn’t break the build. CI pipelines are also leveraged to manage code deployments to all levels, from test through to production. This can be very powerful for testing because, at the push of a button, you can have the version that you need deployed to the environment that requires it.
Every check-in will kick off a build with the latest changes, which allows you to run the tests that you designate to it as soon as the build is done. This is very effective at picking up any potential show-stopping defects, or simply a bad build due to configuration errors. It also allows developers to roll back the changes in source control very easily, instead of having to figure out what change broke the build or caused a defect to appear.
Getting started in CI can be a daunting task because there are many alternatives to consider, each with their own benefits and challenges, and you have to integrate them with your existing systems. Because of the number of potential systems that the CI application will have to interface with, it has to be fairly flexible with different technologies. This can add to the complexity of ramp-up on using the CI systems. For the common tools, there is a lot of helpful content out there and a large helpful community talking about the way they use it.