我想還是定義一下何謂Continuous Integration，Continuous Delivery跟DevOps好了

作者: Wolfken () 看板: Soft_Job
標題: Re: [請益] 這些軟體工程的方法在台灣的普及度?
時間: Wed Jan 29 14:30:09 2014

※ 引述《Wolfken ()》之銘言：
: 目前軟體工程最紅的新方法大概就是DevOps/Continuous Delivery
: 想問一下目前有沒有人的公司正在使用或是想要使用這幾個東西:
: DevOps
: Continuous Delivery
: Continuous Integration
: Test-Driven Development
: 其實前三個應該是同一套的東西，涵蓋的範圍大小不同而已

我想還是定義一下何謂Continuous Integration，Continuous Delivery跟DevOps好了
其中最核心應該是Continuous Integration(CI)


CI想解決的問題是，一般傳統的軟體專案，大部分時間都是各個開發者自行在自己的
電腦上開發，等到搞定了才commit到version control。沒有人會在自己的code搞定
之前去跑跑看跟其他人的code整起來會不會出問題，所以大部分的時間裡，如果把各
個開發者自己電腦上在開發的code包括進來，整個軟體都是處在不能動或是有問題的
狀態，直到接近結尾要release時才會真的穩定下來。

但問題就出在結尾，大家都不先試試看整起來有沒有問題，等到寫了一大堆code，
再去跟其他人也是一大堆的code來整合，通常就會有一堆問題，然後就是無盡的debug
。但因為新code在這種狀況下量很大，debug的複雜度相當高，要花的時間也很長。
這問題即使使用Agile也是無法解決，因為Agile大家還是自己在自己電腦上開發到一
定程度才會commit。

CI或是CD的中心思想就是，如果一件事很麻煩很痛苦，那就把它拆成很多件小事，然
後每天做，甚至一天做好幾次。所以顧名思義，持續整合(CI)就是要每天跟其他人的
code做整合，甚至一天做好幾次。每次都只有幾行到幾十行的code要整合，當然複雜
度就小很多。理念上是這樣，但怎麼落實到實際操作就是一件相當困難的事，需要整
個流程跟使用的系統都大幅調整才有辦法。你的code就不是一個完全版的東西，甚至
連動都還不能動，別人的code也差不多，怎麼能辦到天天整合，甚至一天整好幾次?

CI/CD提出的方法就是基於一個叫做pipeline的東西。所謂pipeline就是從code commit
到version control開始，到真正deploy到production環境中間的流程，包括build test
publish跟deploy。pipeline有四個phase: commit, automated acceptance, manual
test跟release。前兩個phase就是CI，四個phase全包就是CD。pipeline的想法是，把
所有能夠自動化的東西統統自動化，真的不行再去手動做，所以還是有一個手動測試的
phase。基本的要求是unit test跟functional test的自動化測試coverage都要有80%
以上。這麼一來所有人的新code都能隨時跑這些自動化測試，確定自己的code跟大系統
整合起來是沒問題的。也因為大量自動化，所以從code commit到最終deploy只需按一
個按鈕就搞定，而且在一兩小時內搞定。一個CI/CD很重要的指標在於，一行新的code
從commit到使用者實際看到要花多少時間。傳統的方式可能是幾星期甚至更久，但CI/CD
是幾小時。

CI的兩個phase是大量自動化的重點所在。commit phase包括build跟unit test，還有少
量基本的functional test。基本要求是在15分鐘內完成，所以當新code進來時，可以快
速的利用unit test確認沒有問題。通過commit phase的build會進入automated
acceptance phase，這邊是functional test主要跑的地方，要求是30~60分鐘內要跑完。

除了自動化以外，CI的重點是圍繞在自動化pipeline建立一套流程跟紀律，並且搭配新
的文化和想法。舊的方法是build永遠都是處於紅燈(fail)狀態，直到最後要release才
會變綠燈。CI要求build永遠是綠燈，只要任何新code讓它變成紅燈，所有人要停下手
邊的工作，馬上去修正它。這是從Toyota的stop the line學來的，Toyota的產線工人
只要發現問題，可以馬上要求整個生產線停下來，先去處理這個問題。如果commit phase
出問題，開發者有十分鐘可以修正，十分鐘修正不了就是roll back。acceptance phase
出問題則有25~30分鐘。

其他的CI守則包括:
- 不能commit到有問題的build: build只要紅燈，version control就鎖住，任何人
都不能commit。
- 開發者commit前必須在local跑過commit phase的自動化測試
- 開發者commit後必須在電腦前等到commit phase過了才能離開進行下一項工作，所以
commit按下去就去喝下午茶半小時，回來可能會被電到很慘
- 永遠不在build fail時放著不管回家: 這當然不是說要加班到修好為止，是說下班
前一小時就盡量別commit code了
- 永遠不把過不了的test comment掉
- 誰的code讓build fail，那個人就要有肩膀扛下所有責任，並把問題解決
- Test-Driven Development: 除了在code完成時跑自動化測試以外，同樣重要的是使用
test-driven development，在開發過程中不斷確認目前新加的幾十行code是沒問題的
，不要等到寫了上千行，要來commit時，跑下去才發現一堆都fail，這也是在自己電
腦上進行持續整合的方法。一直跟別人的新code整合實際操作上有困難，那麼至少一
直確認你的新code都能通過測試。

所以CI不是工具，而是一個方法，包括流程 紀律 團隊成員思考模式 組織架構 文化，
當然有許多工具幫忙讓這件事比較容易作到，最有名的就是Jenkins，但其實沒工具
也是能做CI，而用了Jenkins也不等於就是CI，很多公司以為用了Jenkins甚至買了幾
套CD或是DevOps的工具就叫在做CI了，事實上CI的重點從來就不是工具，只用了工具
而沒有用到它核心的方法，那跟傳統的方法根本也沒有差別。

CD包括的就更廣，想解決的問題也更全面，然後DevOps則是再拓展到把operation也包
括進來，不過這些就要再花更多篇幅來講了，暫時就先不說了。

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 118.165.198.156
※ 編輯: Wolfken         來自: 118.165.198.156      (01/29 14:31)
推 ohb:                                                            01/29 14:47
推 bndan:看到認真解釋就該給推了 但CI的部份 能合80%的公司 CODE水準  01/29 14:59
→ bndan:在低也有一定水準...(我說穩定度)                           01/29 15:00
推 lovdkkkk:推                                                     01/29 15:08
推 mrbigmouth:推                                                   01/29 15:22
推 SecretWhale:推                                                  01/29 15:45
推 onthesea:原po真好心推                                           01/29 17:26
推 summerleaves:認真推                                             01/29 17:29
推 typepeter:Push                                                  01/29 21:07
推 idiot1129:推                                                    01/29 21:24