Continuous integration per dollar per day
This article is a translation of the article by James Shore " Continuous Integration on a Dollar Day ." The link to this article came to me in the book " Continuous Software Deployment ".
There is a simpler and cheaper way to implement continuous integration than using a build server like CruiseControl. In fact, it is so simple that you can start to execute it right this second and stop feeling bad because of the IT department, which has not yet approved your request to the build server.
(Want a little unethical secret? What I'm going to tell you is better than using CruiseControl!)
Find a free system builder that you used to develop. Not too old ... he should be able to build. Get a lousy monitor and a free corner. Connect the monitor. Place in front of him an old, broken chair. Comfort is not required ... you will not be here for long.
No, really.
My office, about 2001
')
You can use something else, such as a stuffed animal, if you want. Make him fun and make sure that he doesn’t poke out anyone’s eyes if you “accidentally” throw him too hard (especially if you are a girl). If you don't have anything suitable, don't let that stop you. Improvise. Have fun.
I thought it would help me to “decorate” the facade, but it only made me feel incompetent, so you can forget.
He makes ding when you touch him. No, do not stop, because you do not have a desktop call. Get it later. Now you have an impulse. Lousy computer - there is. Connections - there is. Funny toy - there is. You are a few steps away from continuous integration. (If you are very, very limited in means, then you can completely skip this step.)
Oh! This is the hardest part. The good news: One of the best things about CruiseControl is that it forces you to automate the build. Even better news: continuous integration - what you are going to do is more than just an automated build of CruiseControl, and I'm going to help you get all these goodies. But you still need to automate the build.
Okay, this is hard, I know. If you used your IDE to build before, then creating an automated build will probably seem like a lot of work. At the moment, you can probably create a batch file that runs your IDE and asks it to build. This is not good enough in the long run, so then you have to go back and do everything right.
If you have automatic unit tests, such as JUnit / NUnit tests, then also include them in the assembly.
Before we move on, go to the sickly build computer (see step # 1) and make sure that the build normally runs with the latest code from the version control system. Don't use version control system at all? Hmm ... well ... put the keyboard and move away from the computer. Now repeat after me: “Forgive me, peace, for I have sinned. I will never program again without a version control system. I will immediately go and download TortoiseSVN , install it and start using it. I renounce everything vicious from now on. ”Thank you.
If running an automatic build takes more than ten minutes, stop it. You are not yet ready for continuous integration. You need to work on speeding up the build. You can do something from the following, or you can use CruiseControl, but real continuous integration should not be your goal for today.
[In the original, the author uses the idiomatic expression “Drink the Kool-Aid” (Eng.) - “Sip Kool-Aid”, which in American slang means fanatical following the leader. - Approx. translator]
This is absolutely the 100% most important step on this list. Gather all the members of your team together in the same room.
If someone asks, no, this is not a meeting. You come, do something and come back in five minutes. It is useful. Short. For these reasons, this is not a meeting.
Now, without causing bodily harm, make everyone agree with the following:
If someone complains that it is too difficult, let them know that with continuous integration it will be easy. Hmm, easier. If they still think it is too difficult, politely remind them that their job is in, you know, creating software .
Oh, too harsh. Do not say that. Shit, I just lost ten potential customers. Oops, one more leaves. Eleven.
In fact, it’s really important that “everyone agrees that this is a good idea.” You see, the ability to truly rely on your software build system at any given time is a truly revolutionary part of continuous integration. Imagine how much simpler if you knew that the code you just got from the version control system would just work.
Let me tell you a little story. I am engaged in supporting a part of the open source program called NUnitAsp . Last year I read a course about her. During the class, someone asked me about a feature that was not in NUnitAsp. I looked at the code and found it easy to change. So I made a change (it took a few minutes). Then I completed the build and 96 seconds later a new release file appeared, which I distributed. True story. We even had a reward program. We called it "Find a mistake - win a mug." (We were good: we gave the mugs to everyone, even if they did not find any errors).
Well, you probably weren't there. You need wonderful automated tests for building and releasing versions like the one described. So let me tell a different story. On another project, not so successful, we all worked on different parts of the code. We did our best for daily or so checks, but we didn’t collect the whole project and didn’t run the tests. (Tests? We had no automated tests.) Six months later we tried to integrate into one, but nothing combined with each other. We only needed a week to make the program work. I will not even begin to describe how many mistakes that project had. Continuous integration, even without large tests, means that you will never face this nightmare again.
I don't want to try to convince people that this thing is a good idea. I'm not saying you brush your teeth, do you? However, you still do it. This is good for you . Do not want to do this? Do not do this! Not my problem.
Twelve ... thirteen ... fourteen-fifteen-sixteen ... shit.
In any case, if you do not achieve that everyone agrees to do it, the process will not work. What do you expect for a dollar?
Look here for a checklist suitable for printing.
You are ready to start! Let's go over the prelaunch checklist:
Now let's do it!
To begin, register changes at least twice a day. It is part of "continuity." When you put your hand in, register every hour or two.
Before you take the latest code from the version control system, check to see if anyone has taken a rubber chicken. If someone is working, wait until he completes the registration of changes.
When you register changes, follow these steps:
By the way, when step 5 fails, you will be tempted to just solve this problem directly on the assembly machine. But if you do this, then the next poor fugitive who received the last code will not be able to collect it.
Last but not least, keep the build time no longer than ten minutes. Less than five minutes is even better. If it goes on too long, this process will cease to be a pleasant afternoon / afternoon break and will begin to be a real pain in the ass. A short build time is good for you anyway, because slow builds often mean defects in the testing approach.
Once you have the basics of the work, you can proceed to a real improvement in the use of continuous integration. One option is to make your build standalone. In other words, everything you need to build is in a version control system, and once you get the code, you can disconnect from the network to complete the build. This is good because it makes the build more reliable, which makes it easy to build older versions. It also helps get rid of database configuration and migration errors.
Truly delicious quizzes are also good choices. If you have really amazing tests, then you can publish the product without hesitation.
I also like to make my build script and installation package. People often miss the installer from their testing and integration methods ... then they suffer when it comes time to create an installation package. This is one of those things that are much easier to do if you create it gradually. However, automatic testing of installers is still painful.
And ... I hate to admit it ... but installing a CruiseControl can also be a good idea. But only if you have completed an advanced class. By this time, you are getting a really good foundation (team agreement, quick tests, no build failures) and less likely to slip into bad practice.
Good luck! And don't forget to send me my dollar.
There is a simpler and cheaper way to implement continuous integration than using a build server like CruiseControl. In fact, it is so simple that you can start to execute it right this second and stop feeling bad because of the IT department, which has not yet approved your request to the build server.
(Want a little unethical secret? What I'm going to tell you is better than using CruiseControl!)
Step 1: Find the old development computer
Find a free system builder that you used to develop. Not too old ... he should be able to build. Get a lousy monitor and a free corner. Connect the monitor. Place in front of him an old, broken chair. Comfort is not required ... you will not be here for long.
Step 2: Purchase a rubber chicken
No, really.
My office, about 2001
')
You can use something else, such as a stuffed animal, if you want. Make him fun and make sure that he doesn’t poke out anyone’s eyes if you “accidentally” throw him too hard (especially if you are a girl). If you don't have anything suitable, don't let that stop you. Improvise. Have fun.
I thought it would help me to “decorate” the facade, but it only made me feel incompetent, so you can forget.
Step 3: Buy a desk bell
He makes ding when you touch him. No, do not stop, because you do not have a desktop call. Get it later. Now you have an impulse. Lousy computer - there is. Connections - there is. Funny toy - there is. You are a few steps away from continuous integration. (If you are very, very limited in means, then you can completely skip this step.)
Step 4: Automate the build
Oh! This is the hardest part. The good news: One of the best things about CruiseControl is that it forces you to automate the build. Even better news: continuous integration - what you are going to do is more than just an automated build of CruiseControl, and I'm going to help you get all these goodies. But you still need to automate the build.
Okay, this is hard, I know. If you used your IDE to build before, then creating an automated build will probably seem like a lot of work. At the moment, you can probably create a batch file that runs your IDE and asks it to build. This is not good enough in the long run, so then you have to go back and do everything right.
If you have automatic unit tests, such as JUnit / NUnit tests, then also include them in the assembly.
Before we move on, go to the sickly build computer (see step # 1) and make sure that the build normally runs with the latest code from the version control system. Don't use version control system at all? Hmm ... well ... put the keyboard and move away from the computer. Now repeat after me: “Forgive me, peace, for I have sinned. I will never program again without a version control system. I will immediately go and download TortoiseSVN , install it and start using it. I renounce everything vicious from now on. ”Thank you.
If running an automatic build takes more than ten minutes, stop it. You are not yet ready for continuous integration. You need to work on speeding up the build. You can do something from the following, or you can use CruiseControl, but real continuous integration should not be your goal for today.
Step 5: Build everyone under your banner
[In the original, the author uses the idiomatic expression “Drink the Kool-Aid” (Eng.) - “Sip Kool-Aid”, which in American slang means fanatical following the leader. - Approx. translator]
This is absolutely the 100% most important step on this list. Gather all the members of your team together in the same room.
If someone asks, no, this is not a meeting. You come, do something and come back in five minutes. It is useful. Short. For these reasons, this is not a meeting.
Now, without causing bodily harm, make everyone agree with the following:
"Starting today, our code in the version control system will always successfully collect and pass all tests."
If someone complains that it is too difficult, let them know that with continuous integration it will be easy. Hmm, easier. If they still think it is too difficult, politely remind them that their job is in, you know, creating software .
Oh, too harsh. Do not say that. Shit, I just lost ten potential customers. Oops, one more leaves. Eleven.
In fact, it’s really important that “everyone agrees that this is a good idea.” You see, the ability to truly rely on your software build system at any given time is a truly revolutionary part of continuous integration. Imagine how much simpler if you knew that the code you just got from the version control system would just work.
Let me tell you a little story. I am engaged in supporting a part of the open source program called NUnitAsp . Last year I read a course about her. During the class, someone asked me about a feature that was not in NUnitAsp. I looked at the code and found it easy to change. So I made a change (it took a few minutes). Then I completed the build and 96 seconds later a new release file appeared, which I distributed. True story. We even had a reward program. We called it "Find a mistake - win a mug." (We were good: we gave the mugs to everyone, even if they did not find any errors).
Well, you probably weren't there. You need wonderful automated tests for building and releasing versions like the one described. So let me tell a different story. On another project, not so successful, we all worked on different parts of the code. We did our best for daily or so checks, but we didn’t collect the whole project and didn’t run the tests. (Tests? We had no automated tests.) Six months later we tried to integrate into one, but nothing combined with each other. We only needed a week to make the program work. I will not even begin to describe how many mistakes that project had. Continuous integration, even without large tests, means that you will never face this nightmare again.
I don't want to try to convince people that this thing is a good idea. I'm not saying you brush your teeth, do you? However, you still do it. This is good for you . Do not want to do this? Do not do this! Not my problem.
Twelve ... thirteen ... fourteen-fifteen-sixteen ... shit.
In any case, if you do not achieve that everyone agrees to do it, the process will not work. What do you expect for a dollar?
Step 6: Begin!
Look here for a checklist suitable for printing.
You are ready to start! Let's go over the prelaunch checklist:
- Computer build? There is.
- Funny toy? There is.
- Annoying bell? Optional.
- Automated build? There is.
- Consent group? There is.
Now let's do it!
To begin, register changes at least twice a day. It is part of "continuity." When you put your hand in, register every hour or two.
Before you take the latest code from the version control system, check to see if anyone has taken a rubber chicken. If someone is working, wait until he completes the registration of changes.
When you register changes, follow these steps:
- Run the build / test script locally and make sure it runs at 100%.
- Take the rubber chicken from its resting place. If he is not there, find the person who took him and pester him until he completes the registration of the changes.
- Get the latest version of the code from the repository and run the build script just in case again. If the build fails, then you know that there are some integration issues with the code you just received. Noy and moan, put the chicken back and get the person who last made the changes to help you. Start over when you are ready.
- Register your code.
- Go to the computer assembly, get the latest version of the code from the repository and run the assembly script again. If it fails, return (cancel) your registration. You installed some new programs, or changed environment variables, or set a registry key, or forgot to add a file to the repository, or something else. In any case, you need to solve the problem on your computer and try again. You can hold the chicken for one moment, but give it back (and start again) if someone needs it.
- Ring the bell. (For everyone else, this is a signal to applaud or express joy in some other way. “Yeeeey.”) Put the chicken in place. You are done.
By the way, when step 5 fails, you will be tempted to just solve this problem directly on the assembly machine. But if you do this, then the next poor fugitive who received the last code will not be able to collect it.
Last but not least, keep the build time no longer than ten minutes. Less than five minutes is even better. If it goes on too long, this process will cease to be a pleasant afternoon / afternoon break and will begin to be a real pain in the ass. A short build time is good for you anyway, because slow builds often mean defects in the testing approach.
Why is this better than CruiseControl
- The code in the version control system is always collected and tested. Point.
- If something goes wrong, you know what the problem is. This is either your code (unsuccessful step 1), or integration with someone else's code (unsuccessful step 3), or changes in the environment (unsuccessful step 5). You learn about it right away, which makes fixing it easier.
- You don’t have to fix someone’s erroneous builds because the guys left for lunch without waiting for the CruiseControl to complete.
- You save a short build time (nothing motivates change as long integration), which means the best tests, which will lead to a better design of the project.
Advanced Class
Once you have the basics of the work, you can proceed to a real improvement in the use of continuous integration. One option is to make your build standalone. In other words, everything you need to build is in a version control system, and once you get the code, you can disconnect from the network to complete the build. This is good because it makes the build more reliable, which makes it easy to build older versions. It also helps get rid of database configuration and migration errors.
Truly delicious quizzes are also good choices. If you have really amazing tests, then you can publish the product without hesitation.
I also like to make my build script and installation package. People often miss the installer from their testing and integration methods ... then they suffer when it comes time to create an installation package. This is one of those things that are much easier to do if you create it gradually. However, automatic testing of installers is still painful.
And ... I hate to admit it ... but installing a CruiseControl can also be a good idea. But only if you have completed an advanced class. By this time, you are getting a really good foundation (team agreement, quick tests, no build failures) and less likely to slip into bad practice.
Good luck! And don't forget to send me my dollar.
Source: https://habr.com/ru/post/151854/
All Articles