In a Team development environment where parallel development and testing goes we find a requirement of getting most recent build to test as well as some specific build to give the QA to do testing on. This post describes what all are needed to set up an automated source code integration and build system for an environment where we use Visual Studio for development, source control (SVN in our case) for source depot, and doc/ tracking system (trac in our case).
Why do we need a continuous source code integration and build system? well, this helps the QA team by allowing then to not spend more time in syncing the source and doing a build everytimes or even working on a relatively older build. This works as a perfect backup for your Source Control and also the deployment server. This also allows to align the builds numbers to be same as your assembly\file version and also to the source control label there by making a particular build to be a complete unit in itself in terms of readiness for deployment or using the same for development.
Now coming back to build server where we can use cruise control .NET for source integration along with a couple of batch scripts to control the build number and assembly version. CCNET pings the source control (SVN) after every 30 mins (this is a default value and can be changed) to see if there are any modifications. If there are then it triggers a build and publishes it on the Build Server. Once done sleeps again for 30 mins unless it is Forced for a build in between i.e. you can manually force a build in between sleeps.
The core components of build server are:
1) Cruise Control .NET (CCNET):
Its an open source build and integration engine which can be downloaded freely from http://confluence.public.thoughtworks.org/display/CCNET/DownloadOnce. Once the installation is done CCNET needs to be configured according to your requirements. The config file can be found at “%SYSTEMDRIVE%\Program Files\CruiseControl.NET\Server\ccnet.config”.
2) Batch Scripts:
You might have some tasks to do before the automated build. In our case, we want to shift the version in every new build. It can be done by altering AssemblyVersion attribute defined in AsseblyInfo.cs file(s). Also you might need to get all the green lights in NUnit testings before you build. CCNET integrates with NUnit & NAnt nicely for executing test cases and more powerful automated scripts.
Fpr complete reference on the configuration blocks, check out the project home at http://ccnet.sourceforge.net/CCNET/. If you like to do the same on Linux, you might wanna check out luntbuild
訂閱:
張貼留言 (Atom)
Mercury簡易改裝
有同好有一樣的困擾 - 如何使用自己的data logging軟體,因此寫了這篇來分享我的簡易改裝。 Background 雲豆子 MERCURY roaster 烘豆機的設計是使用自行開發的軟體,來:1. 操控風門/火力; 2. data logging/自動烘焙。 ...
-
等了非常久的 Mercury 烘豆機 終於到貨了。找了水電來接220V就迫不及待開烘了。 Overall 這是一台CP值非常高的機器,可以說是目前(2017年5月)最接近貴森森營業機種的縮小版。 一應鉅全:有下豆槽,小型化的的風門,銀皮收集桶,跟風管。 ...
-
有同好有一樣的困擾 - 如何使用自己的data logging軟體,因此寫了這篇來分享我的簡易改裝。 Background 雲豆子 MERCURY roaster 烘豆機的設計是使用自行開發的軟體,來:1. 操控風門/火力; 2. data logging/自動烘焙。 ...
-
this is bad roast because: 1. ROR is flat 2. under develop cupping is shown that result. ...
沒有留言:
張貼留言