Build Automation System using Cruise Control .NET (CCNET)

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

創業者手中的地圖

每天都有人開始創業之路，每天也都有人走下創業舞台。抱著創業夢的人不計其數，為什麼有人美夢成真？有人卻是夢醒一場空？

倫敦商學院知名的管理教授薩爾 (Donald Sull)，花了五年的時間研究創業個案，歸納出創業者如何在追求機會的同時，也能維持應有的紀律 (discipline)，管理伴隨而來的不確定性。他在史隆管理評論（MIT Sloan Management Review）發表研究結果，提供剛起步的創業者，一步步遵循邁進的創業地圖。

第一步，擬出實用的假設。

創業者必須先定義機會，釐清所需資源、將創造的價值，以及執行計劃等。擬定假設時，必須保持彈性，公司在穩定之前，無可避免都要歷經各種變動。加州的一家創投公司在研究過三百家新公司後發現，失敗公司擁有的一個共同特點是，太早決定了經營模式。

擬定假設時，創業者也要確定自己有能力。篩選創業機會的第一個考量應該是，創業者自問自己的經驗或專業，是否能在這個機會上佔一席之地。創業者除了必須了解顧客、對手、技術、法規之外，還必須找出公司的致命傷及成功關鍵。創業者必須能回答：「現在公司的致命傷是什麼？」（例如財力雄厚的競爭者），也要能回答：「我們壓的寶是什麼？」（例如製造出更好用的捕鼠器。）

第二步，匯集資源。

創業者在進行測試之前，必須先獲得資源，包括有形的資金、設備，以及無形的智慧財產權、收集潛在顧客的資料等。究竟多少的資金才夠？創業者匯集的資源，必須足夠支持他進行第二次的測試。

而且，公司應該先確定經營模式，再僱用核心員工。加州創投公司的那份研究發現，大部份成功的新公司都是在進行過幾次測試，擁有穩定的模式之後，才僱用重要的主管，因為那時候公司才明確知道，主管需要具備的專業與經驗為何。另外，公司可以將與核心測試無關的功能外包，將有限的資源集中。

第三步，設計及執行測試。

常見的做法包括，顧客研究、製造樣品、進行小區域試賣等。測試時，公司可採用部份性的測試，針對某個特定問題收集有用的資訊，這個方法適用於公司已經知道，自己對那個議題不了解時。相對地，全面性的測試，則適用於讓公司發現未知的問題，公司以較小的規模，測試產品的各個面向，例如產品在全國上市前，先在某個地區進行試賣。另外，公司也可採用階段式的測試，例如，新餐廳逐步測試與調整菜單、定價、裝潢等。

無論採用何種測試方法，創業者都要避免測試可能帶來的負面效果，包括拖太久、花太多錢、目標不明確、負責測試的人將成功與否視為個人成敗，以致失去客觀性等。要避免這些情況，公司可以邀請外界專家參與設計測試及評估結果。

創業時如果能抓穩手中的地圖，美夢成真的機率，或許就能高一些。