David Ko的學習之旅

十件有關Continuous Integration的事情
10 things you might not know about continuous integration, by Jeffery Payne

有關Continuous integration相關討論
目前國內對於constinuous integration(CI)的討論還真不太普遍, 目前只有收集到這些. 如果大家有看到一些好文章, 歡迎分享一下.
1. Hudson
a. Hudson+Continuous Integration筆記1
http://scmteamwork.blogspot.com/2009/08/hudsoncontinue-integration1.html

Continuous Integration is an Attitude, Not a Tool
http://jamesshore.com/Blog/Continuous-Integration-is-an-Attitude.html

很多人一提到CI(Continuous Integration), 都會誤解認為它就是一堆Tools所成的集合, 事實上不是這樣的.
首先我們來看agile的宣言

Contrary to popular belief, continuous integration is an attitude, not a tool. It's a shared agreement by the team that:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

CI 是會了達到宣言中的working software, 因而所產生的practices. 也就是說我們不只口頭上說我們要agile, 並且我們的做事方法上, 也會配合agile精神來改變.

那什麼是CI呢?

Assembling software every time code changes

“ … is a software development practice where  members of a team integrate their work frequency…”

Each integration is verified by an automated build (including test) to defect integration errors as quickly as
possible

所以CI是希望程式一有變動, 便能快速確認大家的程式碼, 是否還能運作正常, 讓軟體經常保持在可運作的狀況下.

這也就作者為什麼說CI 是一種態度一種觀念, 而不是一堆tools. 根據作者的經驗, 他的觀點如下,首先他認為CI是:
   1. When we get the latest code from the repository, it will always build successfully and pass all tests.
   2. We will check in our code every two to four hours. (他這裡的經驗是大約是每2~4小時check-in 一次)

他們practice的其中一種作法是:
   1. Before check-in, run the build and tests and make sure they pass.
   2. Tell people not to update from the repository because you're doing an integration.
   3. Check in.
   4. Go to a different machine (often a dedicated "integration machine"), get the latest code from the repository, and make sure latest changes build and pass there, too.
   5. Done--tell people they can update again.

當然要完成這些工作有很多種方法, 一般常見的是利用不同的tools來加速其進行, 這也就是為什麼大家誤解CI就是一堆Tools. 其實是先有這些觀念和流程, 然後才找出一堆tool來配合工作的進行.

當然每個tool有每個tool強項的地方, 不會有一個tool可以解決所有的事情. 所以作者也提到不要一想到CI, 就只記得CI server - CruiseControl, 它也只能完成步驟4的部分內容而已

希望大家對CI的認識, 不要再只是侷限於它是一堆Tools.

在 CI中如何縮短build的時間以增快feedback
from Chapter 4 Building Software at Every Change, Continuous Integration
在CI(Continuous Integration)中, feedback的時間是非常重要的. 在這段時間中, 產生build的時間所佔的比例是非常大. 因此如何縮短build產生的時間, 是run CI的人重要的課題
在CI一書中, 它將build分成三個種類
A. Private Build
- A developer will run a private build prior to committing code to the repository.
- By running a private build, you integrate your changes with the last changes available in the version control repository.
B. Integration Build
- An integration build integrates changes committed to the repository by the team against the mainline (also known as the head or trunk).
- Ideally, an integration build should run on a separate, dedicated machine.
C. Release Build
- A release build readies the software for release to users.
- One of the goals of CI is to create deployable software.
- A release build may occur at the end of an iteration or some other milestone, may include more extensive performance and load tests, and must include any acceptance tests.
當你分好類後, 你可設定不同執行方式來產生build
Build Type         Build Mechanism
===========  ===============================================
Private             On-demand
Integration         On-demand, poll for changes, scheduled, event-driven
Release             On-demand, scheduled
此外Flower還提出stage build 的觀念, 所謂stage build 就是 different types of builds that can be run as part of an integration build. 所以他將 build分成兩類:
A. Lightweight build (commit build)
(1) description
-You first run an initial integration “commit” or lightweight build that integrates the software components and runs unit tests to root out any obvious problems.
(2) possible activies
Compile Source Code, Integrate Database, Run Tests, Run Inspections, Deploy Software
B. Heavyweight build (secondary build)
(1) Description
- After this lightweight build is successful, a more exhaustive integration build is run to include component tests or system tests, inspections, and deployment.
- This supports the practice of “fail builds fast,” described earlier in this chapter.
(2) possible activies
Longer Running Tests(Component, System, Functional, Performance), Code Coverage
 
最後還有一招"Fail Builds Fast"
(1) Good builds know how to fail fast. It is annoying to fail after so many other portions of the build have passed, and you are losing precious time targeting the failed targets.
(2) It all depends on what is more likely to fail most often on a particular project.

Is Pipelined Continous Integration a Good Idea?
Amr Elssamadisy
http://www.infoq.com/news/2007/09/CI_Pipeline

Continuous Integration
CI是最近公司流行要做的practice. 但是很多人還是不知道它是什, 以及它有什麼功用. 因此小弟在此survey了一下,來跟大家介紹.
1. Agile Software Development
不能免俗的先介紹一下agile宣言是什麼, 從這宣言中再導出什麼事CI要focus的
(1) Agile manifesto
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
(2) What is CI
a. Continuous Integration helps us to deliver working software
b. In a nutshell, Continuous Integration (CI) is assembling software every time code changes
c. CI is important because Integrating software often decreases the life-span of a defect
d. From Martin Fowler
   - “ … is a software development practice where  members of a team integrate their work frequency…”
   - Each integration is verified by an automated build (including test) to defect integration errors as quickly as possible