First, we’ll introduce Continuous Integration into the brain

Published on July 05, 2013

First, we’ll introduce Continuous Integration into the brain

    No one denies the fact that Continuous Integration is needed. It seems that everyone understands that building an application and running tests on a regular basis is very useful. To get a fast feedback, find a problem, drive away on a clean machine - that's all cool. This is clear to both project managers and developers, even customers are happy when there is an opportunity to try something soon.

    A manager, as a person who should not go into technical details, at the sight of a past Continuous Integration build, can clearly say whether he is good or bad. Green is good, red is bad. A very simple indicator, and not only for managers, but also for the whole team. Developers look at this situation a little differently.

    Now I work with one team, in which we are slowly moving towards continuous integration and are trying to reduce the time for receiving feedback for developers. A little about why this is very critical for this team. We make several interconnected products that use shared libraries. The work is being done by different teams. Naturally, there are times when one team changes something in a common piece, which breaks the neighboring application, so getting a feedback 1 minute after the check is much better than a day from a colleague who is clearly not happy.

    So, in a team situations are not uncommon when I hear a phrase addressed to QA: “You don’t take the last build, it’s not working in it.” QA answer: “Good.” And I heard such a dialogue 3 times over the past week after the check-in and before the demonstration of the new version to the customer. At the same time, all the builds in the CI system are green. It turns out that developers come up with their own indicator. Let the build be green in your system there, but we better know what works for us and what doesn't. With this approach, the value of building a continuous integration process in general is lost, and without it, of course, you can forget about continuous deployments to production.

    Something must happen that changes the order of things in life, to start thinking somehow differently. The first thing you should pay attention to is tests. Without them, continuous integration is impossible, because it will lie, saying that everything is fine. We will start checking builds with our hands, QA engineers will test one build after another to find the one that is most suitable for production, especially if the customer suddenly comes running with burning eyes and demanding the immediate release of a new version of the product.

    How to start writing tests, how to do it in projects with a bunch of legacy code is a separate topic, but here developers need to be a little braver. Do not be afraid to fail, start writing tests. Bad tests are better than none. They will at least somehow test the system, and the process of continuous integration will finally begin to be beneficial. First of all, it is the team’s benefit.

    The second point, which requires some change in the head, is the attitude to build artifacts. If the build is green, we must not only be sure that the code in the repository works correctly on a certain date. We must learn not to test work through source code at all. This is especially true for QA-engineers (or testers, as they are called in your team). They should take exactly what the build gave out - the final package with the new version. The reason is simple, because when deploying, taking the code from a special brunch or, God forbid, the date, is tantamount to suicide. We will definitely miss something and missed more than once in practice. It is worth taking exactly what the CI system left for us, because it has already done part of the work and there is no need to repeat it with your hands. I really like the phrase my colleague said:

    And, of course, the important point is the team. Who should configure CI? Who understands the problem if the application is built locally, but not on the CI system. Yes, it’s there, a build of engineers, something has broken. Do not forget that you are a team. The team that is responsible for the product and continuous integration is part of your daily life, part of development. Build engineers, do not forget that you are also working on a product, you are nowhere without developers.


    It turns out that the recipe for using Continuous Integration will be automatic tests, the use of build artifacts and a team that will work as a single mechanism to achieve the highest goals. Putting these three ingredients together, we will take a big step towards the final goal - continuous deployment to production and bringing joy to our users.