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.
In March’s PQA Academy session, I’ll be talking about what is entailed in setting up a CI pipeline with Jenkins. I’ll touch on source control a little bit since there are a lot of options there as well.
If you have more questions or concerns about implementing CI, like, “What CI software should I use?”; “Do I have to use a certain source control software?”; or, “Is this right for my project?”, sign-up for the March session of PQA Academy. I’ll be answering these questions and more!
Want to schedule a meeting or learn more about CI? Contact us and don’t forget to RSVP to our PQA Academy session on Thursday, March 29 at 8:00AM PT. At PQA, we pride ourselves in being Canada’s leading experts in software testing.
About Benoît Poudrier
Benoît Poudrier is an Automation Specialist at PQA Testing. Ben has been immersed in programming and QA for over 10 years. He has worked in various roles throughout his career and his experience working with a broad range of clients has provided Ben with a wide array of skills. He has performed manual, functional, automated and performance testing, and he has built regression testing suites for several clients. In addition to training many people on Ranorex automation, he has designed and implemented various automation frameworks while working at PQA. Ben has spent over a year learning about security testing on his own through various online courses and through extensive research on a wide range of security-oriented topics.