July 15, 2014 at 11:23Continuous Integration in 10 lines of code or why BuildBot, Jenkins, TeamCity and the like are needed
The note is designed for those who already know what Continuous Integration is, but have not yet chosen which system to implement at home.
You can read what CI is and why to use it, on Wikipedia and here on Habr: article 1 , article 2 , CI tag .
And I’ll tell you what you should pay attention to when choosing a CI for your project, why you should use a ready-made third-party system and don’t get involved in writing your own “bike”.
It began with the fact that in one IT company there was such a conversation between colleagues from neighboring departments:
K1: Do you have continuous integration?
K2: Yes, tests are run for each commit in the trunk.
Q1: What are they working on?
K2: Own script. We are now moving to Buildbot.
Q1: Maybe I don’t understand something, but what's so complicated? Upset, run tests, send the result, why some Buildbot, is it easier to write yourself?
I have met such reasoning - “why is it any other way than continuous integration, what’s complicated there, now we are fetching the script ourselves” - so I want to show with an example what will most likely be missed in a simple “knee-high” version.
So, we write "your little script." I managed to keep within 10 lines, including shebang, the job in crontab and the setting for sending letters.
The script micro_ci.sh, do not forget to make the file executable:
Create a directory / tmp / micro_ci, in / tmp / micro_ci / wc check out the project.
File /etc/cron.d/micro-ci:
Done! Despite the toy size, this MicroCI can work and be beneficial.
And of course, she misses a lot in comparison with "adult" systems. Let's see in more detail.
MicroCI behavior (line 6 in the script): exactly one kind of “assembly” -
Desirable behavior: the ability to configure different types of builds that would run independently or sequentially one after another (smoke tests, unit tests, assembly of artifacts for calculation, etc.)
MicroCI behavior (lines 3-5 in the script): work with exactly one svn repository - the one from which the working copy is memorized
Desirable behavior: the ability to easily configure builds for several repositories, including in different VCS (svn, git, mercurial, etc.)
MicroCI Behavior (line 4 in the script): work with exactly one branch - the one that is stored in the working copy of / tmp / micro_ci / wc.
Desirable behavior: the ability to run tests and assemblies on some or all brunches in the repository.
MicroCI Behavior (line 2 in crontab): runs once every 10 minutes and tries to get updates from the repository.
Desirable behavior - a variety of schedule options, including different for different builds:
MicroCI behavior (line 2 in the script): runs exactly on the same machine, in the same working copy, no parallel operation is provided.
Desirable behavior: the possibility of parallel assemblies in different worker-builders, launch of workers on different servers (for load balancing and for checking operation on different architectures / OS).
MicroCI behavior (line 1 in crontab): the results of all launches are sent by e-mail to one address.
Desirable behavior: delivery of notifications to different email addresses, as well as via jabber, irc, sms, rss - all that is convenient.
MicroCI behavior (line 1 in crontab): the entire assembly output gets into the letters, and nothing more.
Desired behavior: adaptive notifications (different for successful and unsuccessful builds) with a comment about the test run system itself and links to the web interface.
MicroCI behavior (line 1 in crontab, line 6 of the script): letters are sent after each test run.
Desired behavior - the ability to flexibly configure the conditions for sending notifications:
MicroCI is missing.
If the assembly spawns new files in the working copy, they should be automatically deleted before the next start.
MicroCI is missing.
Desirable behavior: the ability to restart tests on one of the previous revisions - in case it seems that the assembly has fallen due to temporary environmental features.
MicroCI is missing.
Desirable behavior - the ability to easily integrate with other tools used in the team: monitoring, messaging system, wiki, internal blog, etc.
MicroCI is missing.
Desirable behavior: it is possible to load a patch into the CI system before committing, the system itself will apply it to the project code and start all the necessary assemblies and checks. This is especially useful if tests are run under different architectures or OS versions, and it is difficult for the developer to launch them.
For TeamCity, this mode is called Remote Run, Buildbot has trial builds, Jenkins has Patch Parameter Plugin.
MicroCI is missing.
Desirable behavior: the CI system has its own web interface in which you can see the assembly history, statistics, etc.
It is convenient when the CI system is distributed under a free license, and if necessary, you can make your own changes to its code.
MicroCI is written in shell, it is very compact, but very inconvenient for the further development of the program.
If it is likely that you will make changes to the CI code, write plugins and modules for it, then, all other things being equal, you should choose a convenient and powerful programming language in which you already have good expertise.
Of course, our MicroCI also has advantages: it is very, very simple, the “installation” is trivial, no third-party software is required. But if in a real project you try to use it or a similar independent development, sooner or later you will have to implement all or almost all of the features listed above. Are you ready for this? If you are not sure, take the CI side and do not add yourself the work of developing a new supporting project in addition to the main one.
And finally, some of the popular CI systems: Atlassian Bamboo , Buildbot ,CruiseControl (crossed out as being stuck in development), Jenkins , TeamCity , Travis CI (for public repositories on github).
A large list is on Wikipedia .
If the review didn’t include any other important and useful features of CI, write in the comments.
Have a good choice!
You can read what CI is and why to use it, on Wikipedia and here on Habr: article 1 , article 2 , CI tag .
And I’ll tell you what you should pay attention to when choosing a CI for your project, why you should use a ready-made third-party system and don’t get involved in writing your own “bike”.
It began with the fact that in one IT company there was such a conversation between colleagues from neighboring departments:
K1: Do you have continuous integration?
K2: Yes, tests are run for each commit in the trunk.
Q1: What are they working on?
K2: Own script. We are now moving to Buildbot.
Q1: Maybe I don’t understand something, but what's so complicated? Upset, run tests, send the result, why some Buildbot, is it easier to write yourself?
I have met such reasoning - “why is it any other way than continuous integration, what’s complicated there, now we are fetching the script ourselves” - so I want to show with an example what will most likely be missed in a simple “knee-high” version.
So, we write "your little script." I managed to keep within 10 lines, including shebang, the job in crontab and the setting for sending letters.
The script micro_ci.sh, do not forget to make the file executable:
#!/bin/sh
cd /tmp/micro_ci/wc && mkdir /tmp/micro_ci/lock || exit 2
rev=`svn info |grep 'Last Changed Rev' |sed 's/.*: *//'`
svn up
if test `svn info |grep 'Last Changed Rev' |sed 's/.*: *//'` = $rev ; then rmdir /tmp/micro_ci/lock ; exit 0 ; fi
make test || status=$?
rmdir /tmp/micro_ci/lock
exit $status
Create a directory / tmp / micro_ci, in / tmp / micro_ci / wc check out the project.
File /etc/cron.d/micro-ci:
MAILTO=project-tests@company.ru
*/10 * * * * tests /path/to/micro_ci.sh
Done! Despite the toy size, this MicroCI can work and be beneficial.
And of course, she misses a lot in comparison with "adult" systems. Let's see in more detail.
Miscellaneous assemblies
MicroCI behavior (line 6 in the script): exactly one kind of “assembly” -
make test(or something else that is hardcoded in the script). Desirable behavior: the ability to configure different types of builds that would run independently or sequentially one after another (smoke tests, unit tests, assembly of artifacts for calculation, etc.)
Work with repositories
MicroCI behavior (lines 3-5 in the script): work with exactly one svn repository - the one from which the working copy is memorized
/tmp/micro_ci/wc. Desirable behavior: the ability to easily configure builds for several repositories, including in different VCS (svn, git, mercurial, etc.)
Work with branches (brunches)
MicroCI Behavior (line 4 in the script): work with exactly one branch - the one that is stored in the working copy of / tmp / micro_ci / wc.
Desirable behavior: the ability to run tests and assemblies on some or all brunches in the repository.
Assembly schedule
MicroCI Behavior (line 2 in crontab): runs once every 10 minutes and tries to get updates from the repository.
Desirable behavior - a variety of schedule options, including different for different builds:
- for each revision;
- by timer;
- nightly;
- when changing certain “interesting” files;
- etc.
Distributed work
MicroCI behavior (line 2 in the script): runs exactly on the same machine, in the same working copy, no parallel operation is provided.
Desirable behavior: the possibility of parallel assemblies in different worker-builders, launch of workers on different servers (for load balancing and for checking operation on different architectures / OS).
Notification Delivery Method
MicroCI behavior (line 1 in crontab): the results of all launches are sent by e-mail to one address.
Desirable behavior: delivery of notifications to different email addresses, as well as via jabber, irc, sms, rss - all that is convenient.
Notification Format
MicroCI behavior (line 1 in crontab): the entire assembly output gets into the letters, and nothing more.
Desired behavior: adaptive notifications (different for successful and unsuccessful builds) with a comment about the test run system itself and links to the web interface.
Notification Terms
MicroCI behavior (line 1 in crontab, line 6 of the script): letters are sent after each test run.
Desired behavior - the ability to flexibly configure the conditions for sending notifications:
- at each start;
- upon failure;
- with the share of failed tests above a certain threshold;
- when changing the state of the assembly: at the first failure after a series of successes and at the first success after a strip of failures;
- about success send a notification only to the general mailing list, about failure - additionally to the author of the problem commit.
Clear working copy between runs
MicroCI is missing.
If the assembly spawns new files in the working copy, they should be automatically deleted before the next start.
Force restarting tests on a specific revision
MicroCI is missing.
Desirable behavior: the ability to restart tests on one of the previous revisions - in case it seems that the assembly has fallen due to temporary environmental features.
Integration with other intranet services
MicroCI is missing.
Desirable behavior - the ability to easily integrate with other tools used in the team: monitoring, messaging system, wiki, internal blog, etc.
Preliminary assembly
MicroCI is missing.
Desirable behavior: it is possible to load a patch into the CI system before committing, the system itself will apply it to the project code and start all the necessary assemblies and checks. This is especially useful if tests are run under different architectures or OS versions, and it is difficult for the developer to launch them.
For TeamCity, this mode is called Remote Run, Buildbot has trial builds, Jenkins has Patch Parameter Plugin.
Native web interface
MicroCI is missing.
Desirable behavior: the CI system has its own web interface in which you can see the assembly history, statistics, etc.
License, opensource
It is convenient when the CI system is distributed under a free license, and if necessary, you can make your own changes to its code.
The language in which CI is written
MicroCI is written in shell, it is very compact, but very inconvenient for the further development of the program.
If it is likely that you will make changes to the CI code, write plugins and modules for it, then, all other things being equal, you should choose a convenient and powerful programming language in which you already have good expertise.
Conclusion
Of course, our MicroCI also has advantages: it is very, very simple, the “installation” is trivial, no third-party software is required. But if in a real project you try to use it or a similar independent development, sooner or later you will have to implement all or almost all of the features listed above. Are you ready for this? If you are not sure, take the CI side and do not add yourself the work of developing a new supporting project in addition to the main one.
And finally, some of the popular CI systems: Atlassian Bamboo , Buildbot ,
A large list is on Wikipedia .
If the review didn’t include any other important and useful features of CI, write in the comments.
Have a good choice!