Introduction to Continuous Integration
Recently I got on a new project, with the task of creating a small application from scratch. I talk with the tester:
- How do you supply new versions?
- You can like everyone else on the project, through SVN.
- That is, you yourself will build?
- No, I take the binaries from there.
It turns out that a lot of programmers, even having words like Senior or Superior in signatures, never in their life met with the concept of CI, or have little idea what it is. Not finding individual publications on Habré on this topic, I decided to fill the gap, and at the same time, if possible, earn the desired invite.
Continuous Integration, or for short, CI, is a special principle in software development that can make your life a lot easier. If on the fingers, the CI system is a kind of program that monitors your Source Control, and when changes appear there, it automatically tightens them, builds, drives tests (of course, if they are written), and possibly does something else. In case of failure, she lets everyone know about this, first of all to the last committer.
What does this give us? Firstly - at any time we have reliable information about the state of the sources in the system. If the last build was unsuccessful (“dropped”), it means that you cannot take a fresh version of the Sorts Control - it may not even compile, and if it is green, successful, then everything is fine. Secondly, it is very simple to find the culprit of the “celebration” - most likely, this is the last committer - he will be responsible for the “repair”. By the way, in such an environment, the task of the highest priority is to fix the build.
')
If unit testing is used on a project, running it on every build gives some guarantee that there are no regression bugs (when they fixed it in one place and fell off in another).
You can also include various code quality metrics in the build, such as coverage, static analysis, search for duplicate code, etc., automate installation on a test machine, and other similar useful things.
There are quite a lot of CI systems, CruiseControl, CruiseControl.Net, Atlassian Bamboo, Hudson, Microsoft Team Foundation Server, and personally my favorite - TeamCity, though not OpenSource, but still free for small projects come to mind.
So, let us need to run under TeamCity CI for a small .Net project (VS2008SP1), which is stored in SVN, and contains tests on nUnit. As you will see, in order to do this on TeamCity, we will not have to write a single line of code / config.
First, we need a server. Yes, I know, this is already quite a lot, but I am more confident in a positive result if I go to the admins and say: give me a server than if I go to the admins and say: give me, for example, a resharper. So, let's say that we already have a server, we can virtual. We install TeamCity on it simply by clicking next-next-next - the default settings are quite decent. In the future, most installations can also not touch - here I will indicate only those that need to be changed. Well, for the future, it will soon come in handy, put also the .Net Framework of the appropriate version (3.5SP1 in our case) and the Windows SDK.
So, after completing the installation, in TeamCity we create a new project, which is actually just a group for individual build configurations, and in it a new configuration, which I, without further ado, called Build.
One more thing that can be indicated on this page is the path to the binaries, the Artifacts field, for example like this: ProjectName \ bin \ Release \ *. *. In general, artifacts are those files that make sense as build results, it can be binaries, logs, analysis results, anything. Then for each build they can be neatly downloaded from the web interface.
By the way ... Unfortunately, the standard visual studio installation projects vdproj are not compatible with msbuild, which does the dirty work for us inside. Therefore, if we want to receive a ready-made msi as a result of the build, we will have to conjure a little. But more about that later.
Click Next, and find yourself on the page dedicated to version control system. First, you need to create a root VCS. Let me explain: for example, you use the same sorts-control for several projects that lie in neighboring daddies. Then there is no sense in setting up access for each one separately - we simply set up access to the root, and in each configuration we simply indicate which part of the source code we need. So, Create and attach new VCS root, then - Type of VCS (we have Subversion), well, depending on the type - further settings, for svn, there are enough: url, user name and password. At the bottom of the page is a large group of labeling rules settings - this is in case you want to make tags for successful builds, and by the way, from the start, it is set to the standard repository structure. We check the correctness of the entered data with the button Test Connection, save. Returning to the Sorts-Control selection page for our configuration, on which a newly created root appeared at the top, you need to add Checkout rules. It is they who determine what part of the repository will be built. For example, if our project is at the address svn.company.com/trunk/project, then it makes sense to install the root on svn.company.com, and the rule to specify the following:
That is: take what is in SVN at such an address relative to the root, and take it out to the active working folder. All other paths, such as the path to the solution file, the paths to the artifacts, will be set relative to it.
Everything, you can go to the most interesting part: the choice of "runner", that is, the process that will actually execute the build. TeamCity out of the box supports many different runners, including Ant, and Maven, and which is more interesting for us - NAnt, MSBuild and sln200 *.
For a start, we will suit sln2008. From the parameters it is enough to specify the path to the solution file (as already mentioned - relative to the root given by the rule). Next we have a section with NUnit settings - here it is enough to specify the version and the path (s) to the dll files with the tests. Everything. By saving, we will not be thrown to the next page - this is because the configuration has already been created and is usable. Of course, in order to call it Continuous Integration, we need to add a build launch condition - in the right upper part of the interface there is a link numbered 4, Build Triggering. Here you need to put a single bird - Enable triggering when files are checked into VCS. Now you can switch to the Projects page and press the Run button in the Build line. If everything is done correctly (well, if your source code is in order), the icon next to the word Build will turn green, and below will appear the number of successfully completed tests.
Yes, whatever you want. You can enable search for duplicate code or FxCop - the corresponding runners are already included in TeamCity. You can automate the deployment - there will already have more difficult.
Of course, if your project is deployed by simple copying, you can create a configuration based on a simple command-line runner, add dependencies to artifacts from the build, and enjoy.
But what to do if you have, for example, a service or, worse, a database?
Windows service before deployment needs to be stopped, overwritten and started, the database must be re-created or updated.
This is where NAnt or MSBuild comes to your rescue. I wrote scripts on both of them, and it’s hard for me to say that I have special preferences. They are quite the same, each has pros and cons. For example, nant calls the same msbuild to work with Visual Studio projects, msbuild is installed by default with the .net framework. But on the other hand, nant has a rather large library of add-ons nant-contrib. In general - a matter of taste.
So, how to add such a script to our project? Just add to sorts-kontrol, and set the appropriate runner.
A typical project build script for me with a site, windows service and base does the following: build a project, update configurations according to the template, put a maintenans-message on the site, stop the service on the dev server, deploy everything to the x-copy developer server, updates the database with scripts from sorts-control (if necessary, of course), starts the service, removes the maintenans-message. The positive of this script is that it is suitable for deployment to the living environment without changes.
In general, this is a topic for another conversation, I will continue if you like this post.
ps I still promised to tell you how to build vdproj. The correct answer is with Visual Studio. Yes, it should not be regrettably installed on the build server. You can do this for example here .
pps Many thanks to JetBrains for the software.
ppps Even more thanks to Mizgol for an invite.
- How do you supply new versions?
- You can like everyone else on the project, through SVN.
- That is, you yourself will build?
- No, I take the binaries from there.
It turns out that a lot of programmers, even having words like Senior or Superior in signatures, never in their life met with the concept of CI, or have little idea what it is. Not finding individual publications on Habré on this topic, I decided to fill the gap, and at the same time, if possible, earn the desired invite.
Continuous Integration, why, why, and how?
Continuous Integration, or for short, CI, is a special principle in software development that can make your life a lot easier. If on the fingers, the CI system is a kind of program that monitors your Source Control, and when changes appear there, it automatically tightens them, builds, drives tests (of course, if they are written), and possibly does something else. In case of failure, she lets everyone know about this, first of all to the last committer.
What does this give us? Firstly - at any time we have reliable information about the state of the sources in the system. If the last build was unsuccessful (“dropped”), it means that you cannot take a fresh version of the Sorts Control - it may not even compile, and if it is green, successful, then everything is fine. Secondly, it is very simple to find the culprit of the “celebration” - most likely, this is the last committer - he will be responsible for the “repair”. By the way, in such an environment, the task of the highest priority is to fix the build.
')
If unit testing is used on a project, running it on every build gives some guarantee that there are no regression bugs (when they fixed it in one place and fell off in another).
You can also include various code quality metrics in the build, such as coverage, static analysis, search for duplicate code, etc., automate installation on a test machine, and other similar useful things.
So how to cook?
There are quite a lot of CI systems, CruiseControl, CruiseControl.Net, Atlassian Bamboo, Hudson, Microsoft Team Foundation Server, and personally my favorite - TeamCity, though not OpenSource, but still free for small projects come to mind.
So, let us need to run under TeamCity CI for a small .Net project (VS2008SP1), which is stored in SVN, and contains tests on nUnit. As you will see, in order to do this on TeamCity, we will not have to write a single line of code / config.
First, we need a server. Yes, I know, this is already quite a lot, but I am more confident in a positive result if I go to the admins and say: give me a server than if I go to the admins and say: give me, for example, a resharper. So, let's say that we already have a server, we can virtual. We install TeamCity on it simply by clicking next-next-next - the default settings are quite decent. In the future, most installations can also not touch - here I will indicate only those that need to be changed. Well, for the future, it will soon come in handy, put also the .Net Framework of the appropriate version (3.5SP1 in our case) and the Windows SDK.
Getting Started: Configuration
So, after completing the installation, in TeamCity we create a new project, which is actually just a group for individual build configurations, and in it a new configuration, which I, without further ado, called Build.
One more thing that can be indicated on this page is the path to the binaries, the Artifacts field, for example like this: ProjectName \ bin \ Release \ *. *. In general, artifacts are those files that make sense as build results, it can be binaries, logs, analysis results, anything. Then for each build they can be neatly downloaded from the web interface.
By the way ... Unfortunately, the standard visual studio installation projects vdproj are not compatible with msbuild, which does the dirty work for us inside. Therefore, if we want to receive a ready-made msi as a result of the build, we will have to conjure a little. But more about that later.
Version Control System
Click Next, and find yourself on the page dedicated to version control system. First, you need to create a root VCS. Let me explain: for example, you use the same sorts-control for several projects that lie in neighboring daddies. Then there is no sense in setting up access for each one separately - we simply set up access to the root, and in each configuration we simply indicate which part of the source code we need. So, Create and attach new VCS root, then - Type of VCS (we have Subversion), well, depending on the type - further settings, for svn, there are enough: url, user name and password. At the bottom of the page is a large group of labeling rules settings - this is in case you want to make tags for successful builds, and by the way, from the start, it is set to the standard repository structure. We check the correctness of the entered data with the button Test Connection, save. Returning to the Sorts-Control selection page for our configuration, on which a newly created root appeared at the top, you need to add Checkout rules. It is they who determine what part of the repository will be built. For example, if our project is at the address svn.company.com/trunk/project, then it makes sense to install the root on svn.company.com, and the rule to specify the following:
+:trunk/project=>.That is: take what is in SVN at such an address relative to the root, and take it out to the active working folder. All other paths, such as the path to the solution file, the paths to the artifacts, will be set relative to it.
Actually bildim: "runner"
Everything, you can go to the most interesting part: the choice of "runner", that is, the process that will actually execute the build. TeamCity out of the box supports many different runners, including Ant, and Maven, and which is more interesting for us - NAnt, MSBuild and sln200 *.
For a start, we will suit sln2008. From the parameters it is enough to specify the path to the solution file (as already mentioned - relative to the root given by the rule). Next we have a section with NUnit settings - here it is enough to specify the version and the path (s) to the dll files with the tests. Everything. By saving, we will not be thrown to the next page - this is because the configuration has already been created and is usable. Of course, in order to call it Continuous Integration, we need to add a build launch condition - in the right upper part of the interface there is a link numbered 4, Build Triggering. Here you need to put a single bird - Enable triggering when files are checked into VCS. Now you can switch to the Projects page and press the Run button in the Build line. If everything is done correctly (well, if your source code is in order), the icon next to the word Build will turn green, and below will appear the number of successfully completed tests.
How to develop?
Yes, whatever you want. You can enable search for duplicate code or FxCop - the corresponding runners are already included in TeamCity. You can automate the deployment - there will already have more difficult.
Of course, if your project is deployed by simple copying, you can create a configuration based on a simple command-line runner, add dependencies to artifacts from the build, and enjoy.
But what to do if you have, for example, a service or, worse, a database?
Windows service before deployment needs to be stopped, overwritten and started, the database must be re-created or updated.
This is where NAnt or MSBuild comes to your rescue. I wrote scripts on both of them, and it’s hard for me to say that I have special preferences. They are quite the same, each has pros and cons. For example, nant calls the same msbuild to work with Visual Studio projects, msbuild is installed by default with the .net framework. But on the other hand, nant has a rather large library of add-ons nant-contrib. In general - a matter of taste.
So, how to add such a script to our project? Just add to sorts-kontrol, and set the appropriate runner.
A typical project build script for me with a site, windows service and base does the following: build a project, update configurations according to the template, put a maintenans-message on the site, stop the service on the dev server, deploy everything to the x-copy developer server, updates the database with scripts from sorts-control (if necessary, of course), starts the service, removes the maintenans-message. The positive of this script is that it is suitable for deployment to the living environment without changes.
In general, this is a topic for another conversation, I will continue if you like this post.
ps I still promised to tell you how to build vdproj. The correct answer is with Visual Studio. Yes, it should not be regrettably installed on the build server. You can do this for example here .
pps Many thanks to JetBrains for the software.
ppps Even more thanks to Mizgol for an invite.
Source: https://habr.com/ru/post/82724/
All Articles