Continuous integration per dollar per day
This article is a translation of James Shore's article " Continuous Integration on a Dollar a 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 executing it right this second and stop feeling ill 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 the free system unit that you used to use for development. Not too old ... he should be able to complete the assembly. Get a lousy monitor and free angle. Connect the monitor. Place an old, broken chair in front of him. Comfort is not required ... you will not be here for long.
No really.
My office, around 2001.
You can use something else, for example, a stuffed animal, if you want. Make it fun and make sure that it doesn’t poke your eyes out if you “accidentally” throw it too hard (especially if you're a girl). If you do not have anything suitable, let this not stop you. Improvise. Have fun.
I thought it would help me “decorate” the facade, but it only made me feel incompetent, so you can forget.
He does the jin when you touch him. No, don’t stop because you don’t have a desk call. Get it later. Now you have an impulse. There is a lousy computer. Connections - there is. Funny toy - available. You are steps away from continuous integration. (If you are very, very limited in funds, 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 before that you used your IDE for assembly, then creating an automated assembly will probably seem like a lot of work. At the moment, you can probably create a batch file that launches 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 it right.
If you have automated unit tests, such as JUnit / NUnit tests, then also include them in the assembly.
Before we move on, go to the frail build computer (see step # 1) and make sure that the build is working properly with the latest code from the version control system. Don't use version control at all? Hmm ... okay ... put the keyboard down and get away from the computer. Now repeat after me: “Forgive me, world, for I have sinned. I will never program again without a version control system. I will go now and download TortoiseSVN , install it and start using it. I renounce everything vicious from now on. ” Thanks.
If running a fully automated 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 one of 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 jargon means fanatical following the leader. - Note translator]
This is absolutely indisputable, 100% the most important step on this list. Gather all your team members together in one room.
If someone asks, then no, this is not a meeting. You come, do something and come back in five minutes. Useful Short. For these reasons, this is not a meeting.
Now, without causing bodily harm, make everyone agree to the following:
If someone complains that this is too complicated, let them know that with continuous integration it will be easy. Hmm, easier. If they still think it's too complicated, politely remind them that their job is to, you know, create software .
Oh, too harsh. Do not say that. Shit, I just lost ten potential customers. Oops, another one is leaving. 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 really a revolutionary part of continuous integration. Imagine how much easier would be life 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 supporting a part of the open source program called NUnitAsp. Last year I taught a course about her. During the lesson, 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 assembly and 96 seconds later a new release file appeared, which I handed out. True story. We even had a reward program. We called it "Find a mistake - win a mug." (We were good: we gave circles to everyone, even if they did not find any mistakes).
Well, you probably weren't there. You need some great automated tests to build and release versions like the one described. So let me tell you another story. On another project, not so successful, we all worked on different parts of the code. We did our best for daily checks or so, but we did not collect the entire project and did not run the tests. (Tests? We did not have any automated tests.) Six months later, we tried to integrate into one whole, but nothing was combined with each other. It took us a week to get the program to work. I will not even begin to describe how many mistakes that project had. Continuous integration, even without big tests, means that you will never face this nightmare again.
I do not want to try to convince people that this thing is a good idea. I'm not saying that you brush your teeth, right? However, you are still doing this. 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 get everyone to agree to do this, the process will not work. What do you expect for a dollar?
Check here for a printable checklist.
Are you ready to start! Let's go over the pre-launch checklist:
Now let's do it!
To begin, record changes at least twice a day. This is part of "continuity." When you fill your hand, register every hour or two.
Before you get the latest code from the version control system, check to see if anyone has taken a rubber chicken. If someone is working, wait until they complete the change registration.
When you register changes, follow these steps:
By the way, when step 5 fails, you will be tempted to simply solve this problem directly on the build machine. But if you do this, then the next poor poor guy who received the latest code will not be able to collect it.
Last but not least, keep the build time not more than ten minutes. Less than five minutes, even better. If it takes too long, this process will cease to be a pleasant midday / 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 flaws in the testing approach.
Once you have the basics of work, you can move on to real improvement in the use of continuous integration. One option is to make your build standalone. In other words, everything you need to collect is in the version control system, and as soon as you receive the code, you can disconnect from the network to complete the assembly. This is good because it makes the build more reliable, which makes it easy to build old versions. It also helps to get rid of database configuration and migration errors.
Really amazing tests are also a good choice. If you have truly amazing tests, then you can publish the product without hesitation.
I also like to have my build script create the installation package as well. 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 is 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 CruiseControl might 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 it’s less likely that you will 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 executing it right this second and stop feeling ill 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 an Old Development Computer
Find the free system unit that you used to use for development. Not too old ... he should be able to complete the assembly. Get a lousy monitor and free angle. Connect the monitor. Place an old, broken chair in front of him. Comfort is not required ... you will not be here for long.
Step 2: Get A Rubber Chicken
No really.
My office, around 2001.
You can use something else, for example, a stuffed animal, if you want. Make it fun and make sure that it doesn’t poke your eyes out if you “accidentally” throw it too hard (especially if you're a girl). If you do not have anything suitable, let this not stop you. Improvise. Have fun.
I thought it would help me “decorate” the facade, but it only made me feel incompetent, so you can forget.
Step 3: Buy a desk call
He does the jin when you touch him. No, don’t stop because you don’t have a desk call. Get it later. Now you have an impulse. There is a lousy computer. Connections - there is. Funny toy - available. You are steps away from continuous integration. (If you are very, very limited in funds, 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 before that you used your IDE for assembly, then creating an automated assembly will probably seem like a lot of work. At the moment, you can probably create a batch file that launches 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 it right.
If you have automated unit tests, such as JUnit / NUnit tests, then also include them in the assembly.
Before we move on, go to the frail build computer (see step # 1) and make sure that the build is working properly with the latest code from the version control system. Don't use version control at all? Hmm ... okay ... put the keyboard down and get away from the computer. Now repeat after me: “Forgive me, world, for I have sinned. I will never program again without a version control system. I will go now and download TortoiseSVN , install it and start using it. I renounce everything vicious from now on. ” Thanks.
If running a fully automated 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 one of the following, or you can use CruiseControl, but real continuous integration should not be your goal for today.
Step 5: Build Everyone Under Your Banners
[In the original, the author uses the idiomatic expression “Drink the Kool-Aid” (Eng.) - “Sip Kool-Aid”, which in American jargon means fanatical following the leader. - Note translator]
This is absolutely indisputable, 100% the most important step on this list. Gather all your team members together in one room.
If someone asks, then no, this is not a meeting. You come, do something and come back in five minutes. Useful Short. For these reasons, this is not a meeting.
Now, without causing bodily harm, make everyone agree to the following:
“From today, our code in the version control system will always successfully collect and pass all the tests.”
If someone complains that this is too complicated, let them know that with continuous integration it will be easy. Hmm, easier. If they still think it's too complicated, politely remind them that their job is to, you know, create software .
Oh, too harsh. Do not say that. Shit, I just lost ten potential customers. Oops, another one is leaving. 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 really a revolutionary part of continuous integration. Imagine how much easier would be life 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 supporting a part of the open source program called NUnitAsp. Last year I taught a course about her. During the lesson, 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 assembly and 96 seconds later a new release file appeared, which I handed out. True story. We even had a reward program. We called it "Find a mistake - win a mug." (We were good: we gave circles to everyone, even if they did not find any mistakes).
Well, you probably weren't there. You need some great automated tests to build and release versions like the one described. So let me tell you another story. On another project, not so successful, we all worked on different parts of the code. We did our best for daily checks or so, but we did not collect the entire project and did not run the tests. (Tests? We did not have any automated tests.) Six months later, we tried to integrate into one whole, but nothing was combined with each other. It took us a week to get the program to work. I will not even begin to describe how many mistakes that project had. Continuous integration, even without big tests, means that you will never face this nightmare again.
I do not want to try to convince people that this thing is a good idea. I'm not saying that you brush your teeth, right? However, you are still doing this. 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 get everyone to agree to do this, the process will not work. What do you expect for a dollar?
Step 6: Get Started!
Check here for a printable checklist.
Are you ready to start! Let's go over the pre-launch checklist:
- Computer assembly? There is.
- Funny toy? There is.
- An annoying call? Optional.
- Automated build? There is.
- Group Consent? There is.
Now let's do it!
To begin, record changes at least twice a day. This is part of "continuity." When you fill your hand, register every hour or two.
Before you get the latest code from the version control system, check to see if anyone has taken a rubber chicken. If someone is working, wait until they complete the change registration.
When you register changes, follow these steps:
- Run the build / test script locally and make sure it runs 100%.
- Pick up the rubber chicken from its resting place. If he is not there, find the person who picked him up and pester him until he completes the registration of the changes.
- Get the latest code from the repository and run the build script just in case again. If the assembly fails, then you know that there are some integration problems with the code you just received. Wail and moan, put the chicken back and get the person who made the last changes to help you. Start over when you are ready.
- Register your code.
- Go to the build computer, get the latest code from the repository, and run the build script again. If it does not pass, return (cancel) your registration. You installed some new programs, or changed environment variables, or set the registry parameter, or forgot to add the 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 on to the chicken for a moment, but give it back (and start over) if someone needs it.
- Ring the bell. (For everyone else, this is a signal to applaud or express joy somehow. "Yeeee"). Put the chicken in place. You are done.
By the way, when step 5 fails, you will be tempted to simply solve this problem directly on the build machine. But if you do this, then the next poor poor guy who received the latest code will not be able to collect it.
Last but not least, keep the build time not more than ten minutes. Less than five minutes, even better. If it takes too long, this process will cease to be a pleasant midday / 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 flaws in the testing approach.
Why is it better than CruiseControl
- Code in the version control system is always compiled 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 will learn about it right away, which makes its correction easier.
- You don’t have to fix someone’s erroneous builds because the guys left for lunch without waiting for CruiseControl to complete.
- You save a short build time (nothing motivates you to change like a long integration), which means better tests, which will lead to a better design of the project.
Advanced class
Once you have the basics of work, you can move on to real improvement in the use of continuous integration. One option is to make your build standalone. In other words, everything you need to collect is in the version control system, and as soon as you receive the code, you can disconnect from the network to complete the assembly. This is good because it makes the build more reliable, which makes it easy to build old versions. It also helps to get rid of database configuration and migration errors.
Really amazing tests are also a good choice. If you have truly amazing tests, then you can publish the product without hesitation.
I also like to have my build script create the installation package as well. 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 is 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 CruiseControl might 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 it’s less likely that you will slip into bad practice.
Good luck And don't forget to send me my dollar.