The system of continuous integration do it yourself
Good day, % username% !
About continuous integration, you can read here and generally look for literature on this topic, if it becomes interesting. If you have already realized all the benefits of using CI, then continue to develop the idea. The most popular of the existing systems of continuous integration: Hudson, TeamCity and CruiseControl. In all these systems, the build is usually configured via the UI. Choose what to do in the browser window - and the build is automated (of course, you can write your own scripts and run them). The abundance of settings and all sorts of lotions. And I thought, what did the creators of these systems do? And they just made teams for various builders, compilers, testing and other tools, so that the developer does not spend his time on these things. Is it really a lot of time to write your own system and commands?
For small projects I use only a few tools:
so why not study the command line options for the tools I need, write a couple of scripts and automate the whole process. I'm not saying that this is the best solution, I just wanted to invent this wonderful bike called CI.
When developing more or less serious applications in decent companies use a version control system . And most of them have such hooks (hooks) - repository event handlers. It was this method of automation that first came to my mind.
As VCS, we will use svn (in fact, in other systems, differences in hooks are minimal, or none at all).
')
1. Create a repository.
2. Go to the hooks folder and create a post-commit.bat there. In this batch file, we will write a command that must be executed after each commit.
3. Make a checkout from the repository. Create a folder CI, so as not to litter the root directory. In the CI folder we create the Run.bat file, in which our entire process will be described.
4. In the post-commit.bat run Run.bat - that's all the automation
post-commit.bat:
D: \ Work \ SomeProject \ CI \ Run.bat
The project under development is a .NET class library with a set of tests.
Of course, this is not a complete list of CI functions, but I do not try to cover all the platforms, and take into account the specifics of all development methodologies.
To do this, simply run the svn update command. With each change, the update will take a minimum of time (as an option, you can clear the entire folder and checkout)
For these purposes, we use the msbuild script:
The results of MSBuild execution are placed in the CI \ Logs folder by redirecting the standard output stream to a file.
Most CI systems have the ability to send emails with notifications, but for such modest purposes I didn’t want to send a letter and litter my mailbox, so I decided to limit myself to sending a message in ICQ. Using the NOscar library, I wrote a small console application that is flexibly configured and sends a message to the uin list. The message will be generated based on the search in the previously received build log of the string “Build succeeded.”
CI \ Run.bat:
The result was a fairly lightweight automated CI system, which can be easily and profitably expanded by studying the tools with which you work. And, importantly, the process becomes more visual, due to the cleanliness of the directories (there is no bundle of universal scripts that we do not use).
Thanks for attention
PS: There is an idea to write a sort of factory for generating such scripts. I wanted a script - went to the site - a couple of consecutive pages with useful tips and hints - you get to download a script file - threw it into a folder - that's it. Of course, with the power of modern servers it is easier to put one of the existing ones, but still more pleasant, when there is nothing superfluous in the folders, a clearer picture of what is happening, nothing confuses.
About continuous integration, you can read here and generally look for literature on this topic, if it becomes interesting. If you have already realized all the benefits of using CI, then continue to develop the idea. The most popular of the existing systems of continuous integration: Hudson, TeamCity and CruiseControl. In all these systems, the build is usually configured via the UI. Choose what to do in the browser window - and the build is automated (of course, you can write your own scripts and run them). The abundance of settings and all sorts of lotions. And I thought, what did the creators of these systems do? And they just made teams for various builders, compilers, testing and other tools, so that the developer does not spend his time on these things. Is it really a lot of time to write your own system and commands?
For small projects I use only a few tools:
- .NET development platform
- MS SQL Server for databases
- NUnit for testing
- ... maybe a couple more tools
so why not study the command line options for the tools I need, write a couple of scripts and automate the whole process. I'm not saying that this is the best solution, I just wanted to invent this wonderful bike called CI.
When developing more or less serious applications in decent companies use a version control system . And most of them have such hooks (hooks) - repository event handlers. It was this method of automation that first came to my mind.
As VCS, we will use svn (in fact, in other systems, differences in hooks are minimal, or none at all).
')
1. Create a repository.
2. Go to the hooks folder and create a post-commit.bat there. In this batch file, we will write a command that must be executed after each commit.
3. Make a checkout from the repository. Create a folder CI, so as not to litter the root directory. In the CI folder we create the Run.bat file, in which our entire process will be described.
4. In the post-commit.bat run Run.bat - that's all the automation
post-commit.bat:
D: \ Work \ SomeProject \ CI \ Run.bat
The project under development is a .NET class library with a set of tests.
So, let's define the functions for our CI system.
- Getting the source code from the repository
- Quick build after commit and run unit tests after build
- Build Result Notification
Of course, this is not a complete list of CI functions, but I do not try to cover all the platforms, and take into account the specifics of all development methodologies.
1. Getting the source code from the repository
To do this, simply run the svn update command. With each change, the update will take a minimum of time (as an option, you can clear the entire folder and checkout)
2. Quick build after commit and launch unit tests after build
For these purposes, we use the msbuild script:
<? xml version = "1.0" encoding = "utf-8" ?>
<Project DefaultTargets = "Test" xmlns = " schemas.microsoft.com/developer/msbuild/2003" >
<! - Import the MSBuild Tasks ->
<Import Project = "$ (MSBuildExtensionsPath) \ MSBuildCommunityTasks \ MSBuild.Community.Tasks.Targets" />
<PropertyGroup >
<Configuration Condition = "'$ (Configuration)' == ''" > Debug </ Configuration >
<ClassLibraryOutputDirectory > bin \ $ (Configuration) </ ClassLibraryOutputDirectory >
<ProjectDir > SomeSolution \ SomeProject </ ProjectDir >
<ProjectTestDir > SomeSolution \ SomeTests </ ProjectTestDir >
<ProjectFile > $ (ProjectDir) \ SomeProject.csproj </ ProjectFile >
<TestProjectFile > $ (ProjectTestDir) \ SomeTests.csproj </ TestProjectFile >
</ PropertyGroup >
<! - Build projects by the project files generated by VS ->
<Target Name = "Build" >
<MSBuild Projects = "$ (ProjectFile)" />
<MSBuild Projects = "$ (TestProjectFile)" />
</ Target >
<! - Run Unit tests ->
<Target Name = "Test" DependsOnTargets = "Build" >
<Exec Command = "" % PROGRAMFILES% \ NUnit 2.5.10 \ bin \ net-2.0 \ nunit-console.exe "$ (ProjectTestDir) \ $ (ClassLibraryOutputDirectory) \ SomeTests.dll / xmlConsole" />
</ Target >
</ Project >
The results of MSBuild execution are placed in the CI \ Logs folder by redirecting the standard output stream to a file.
3. Notification of build result
Most CI systems have the ability to send emails with notifications, but for such modest purposes I didn’t want to send a letter and litter my mailbox, so I decided to limit myself to sending a message in ICQ. Using the NOscar library, I wrote a small console application that is flexibly configured and sends a message to the uin list. The message will be generated based on the search in the previously received build log of the string “Build succeeded.”
All the steps seem to be worked out, it remains to perform them sequentially.
CI \ Run.bat:
cd / d ...
REM 1. Get Last sources
svn update
REM 2. Build and Run Unit Tests
" % windir % \ Microsoft .NET \ Framework \ v3.5 \ msbuild.exe" Master.build> CI \ Logs \ build.log
REM 3. Send notification
set "Message = Build succeeded."
find "Build succeeded." CI \ Logs \ build.log> NUL
if % errorlevel % equ 1 set "Message = Build failed."
CI \ Notifier \ ICQSender.exe " % Message % "
The result was a fairly lightweight automated CI system, which can be easily and profitably expanded by studying the tools with which you work. And, importantly, the process becomes more visual, due to the cleanliness of the directories (there is no bundle of universal scripts that we do not use).
Thanks for attention
PS: There is an idea to write a sort of factory for generating such scripts. I wanted a script - went to the site - a couple of consecutive pages with useful tips and hints - you get to download a script file - threw it into a folder - that's it. Of course, with the power of modern servers it is easier to put one of the existing ones, but still more pleasant, when there is nothing superfluous in the folders, a clearer picture of what is happening, nothing confuses.
Source: https://habr.com/ru/post/126971/
All Articles