To begin with we will implement Continuous Integration in a brain
The fact that Continuous Integration is needed is no longer denied. It seems to be clear to everyone that it is very useful to build an application, to run tests on a regular basis. Get a quick feedback, find a problem, drive away on a clean machine - this is all cool. This is understandable both to project managers and developers, even customers are happy when there is an opportunity to try something quickly.
A manager, like a person who does not have to go into the technical details, at the sight of a past Continuous Integration build, can unequivocally 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 am working 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. Work goes by different teams. Naturally, there are cases when one team changes something in a common piece that breaks a neighboring application, so getting a feedback after 1 minute after checkin is much better than a day from a colleague who is clearly unsatisfied.
So, in a team, situations are not rare when I hear such 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 in the past week after the check-ins and before the demonstration of the new version to the customer. At the same time, all builds in the CI system are green. It turns out that developers invent their own indicator. Let the build be green in your system there, but we know better what is working and what is not. With this approach, the value of building the process of continuous integration in general is lost, and without it, of course, you can forget about the continuous depositions on production.
')
Something must happen that changes the order of things in life, start thinking in some other way. The first thing worth paying 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 this in projects for a bunch of legacy code is a separate topic, but 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 check the system, and the process of continuous integration will finally begin to bring benefits. First of all, it is the team that benefits.
The second point that requires some change in the head is the attitude to the artifacts of the build. If the build is green, we should not just be sure that the code in the repository on such and such a date works correctly. We have to learn not to test work through the source code at all. Especially, it concerns QA-engineers (or testers, as they are called in your team). They must take exactly what the build gave out - the final package with the new version. The reason is simple, because with a delay, taking a code from a special brunch or, God forbid, on 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 us, because it has already done some of the work and there is no need to repeat it with our hands. I really like the phrase my colleague said: “At night, computers come together and laugh at people if they do the work that computers could do.”
And, of course, the important point is the team. Who should set up CI? Who understands the problem if the application is built locally, but not on the CI system. Yes it is you there, build engineers, something broke. 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 the use of 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 - the continuous deployment of production and the delivery of joy to our users.
A manager, like a person who does not have to go into the technical details, at the sight of a past Continuous Integration build, can unequivocally 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 am working 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. Work goes by different teams. Naturally, there are cases when one team changes something in a common piece that breaks a neighboring application, so getting a feedback after 1 minute after checkin is much better than a day from a colleague who is clearly unsatisfied.
So, in a team, situations are not rare when I hear such 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 in the past week after the check-ins and before the demonstration of the new version to the customer. At the same time, all builds in the CI system are green. It turns out that developers invent their own indicator. Let the build be green in your system there, but we know better what is working and what is not. With this approach, the value of building the process of continuous integration in general is lost, and without it, of course, you can forget about the continuous depositions on production.
')
Something must happen that changes the order of things in life, start thinking in some other way. The first thing worth paying 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 this in projects for a bunch of legacy code is a separate topic, but 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 check the system, and the process of continuous integration will finally begin to bring benefits. First of all, it is the team that benefits.
The second point that requires some change in the head is the attitude to the artifacts of the build. If the build is green, we should not just be sure that the code in the repository on such and such a date works correctly. We have to learn not to test work through the source code at all. Especially, it concerns QA-engineers (or testers, as they are called in your team). They must take exactly what the build gave out - the final package with the new version. The reason is simple, because with a delay, taking a code from a special brunch or, God forbid, on 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 us, because it has already done some of the work and there is no need to repeat it with our hands. I really like the phrase my colleague said: “At night, computers come together and laugh at people if they do the work that computers could do.”
And, of course, the important point is the team. Who should set up CI? Who understands the problem if the application is built locally, but not on the CI system. Yes it is you there, build engineers, something broke. 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 the use of 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 - the continuous deployment of production and the delivery of joy to our users.
Source: https://habr.com/ru/post/185740/
All Articles