※ 本文為 windows2k.bbs. 轉寄自 ptt.cc 更新時間: 2016-01-15 10:33:50
看板 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時才會真的穩定下來。
電腦上開發，等到搞定了才commit到version control。沒有人會在自己的code搞定
之前去跑跑看跟其他人的code整起來會不會出問題，所以大部分的時間裡，如果把各
個開發者自己電腦上在開發的code包括進來，整個軟體都是處在不能動或是有問題的
狀態，直到接近結尾要release時才會真的穩定下來。
但問題就出在結尾，大家都不先試試看整起來有沒有問題，等到寫了一大堆code，
再去跟其他人也是一大堆的code來整合，通常就會有一堆問題，然後就是無盡的debug
。但因為新code在這種狀況下量很大，debug的複雜度相當高，要花的時間也很長。
這問題即使使用Agile也是無法解決，因為Agile大家還是自己在自己電腦上開發到一
定程度才會commit。
這問題即使使用Agile也是無法解決，因為Agile大家還是自己在自己電腦上開發到一
定程度才會commit。
CI或是CD的中心思想就是，如果一件事很麻煩很痛苦，那就把它拆成很多件小事，然
後每天做，甚至一天做好幾次。所以顧名思義，持續整合(CI)就是要每天跟其他人的
code做整合，甚至一天做好幾次。每次都只有幾行到幾十行的code要整合，當然複雜
度就小很多。理念上是這樣，但怎麼落實到實際操作就是一件相當困難的事，需要整
個流程跟使用的系統都大幅調整才有辦法。你的code就不是一個完全版的東西，甚至
連動都還不能動，別人的code也差不多，怎麼能辦到天天整合，甚至一天整好幾次?
後每天做，甚至一天做好幾次。所以顧名思義，持續整合(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
到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%
所有能夠自動化的東西統統自動化，真的不行再去手動做，所以還是有一個手動測試的
phase。基本的要求是unit test跟functional test的自動化測試coverage都要有80%
以上。這麼一來所有人的新code都能隨時跑這些自動化測試，確定自己的code跟大系統
整合起來是沒問題的。也因為大量自動化，所以從code commit到最終deploy只需按一
個按鈕就搞定，而且在一兩小時內搞定。一個CI/CD很重要的指標在於，一行新的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
量基本的functional test。基本要求是在15分鐘內完成，所以當新code進來時，可以快
速的利用unit test確認沒有問題。通過commit phase的build會進入automated
acceptance phase，這邊是functional test主要跑的地方，要求是30~60分鐘內要跑完。
除了自動化以外，CI的重點是圍繞在自動化pipeline建立一套流程跟紀律，並且搭配新
除了自動化以外，CI的重點是圍繞在自動化pipeline建立一套流程跟紀律，並且搭配新
的文化和想法。舊的方法是build永遠都是處於紅燈(fail)狀態，直到最後要release才
會變綠燈。CI要求build永遠是綠燈，只要任何新code讓它變成紅燈，所有人要停下手
邊的工作，馬上去修正它。這是從Toyota的stop the line學來的，Toyota的產線工人
會變綠燈。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都能通過測試。
腦上進行持續整合的方法。一直跟別人的新code整合實際操作上有困難，那麼至少一
直確認你的新code都能通過測試。
所以CI不是工具，而是一個方法，包括流程 紀律 團隊成員思考模式 組織架構 文化，
當然有許多工具幫忙讓這件事比較容易作到，最有名的就是Jenkins，但其實沒工具
也是能做CI，而用了Jenkins也不等於就是CI，很多公司以為用了Jenkins甚至買了幾
套CD或是DevOps的工具就叫在做CI了，事實上CI的重點從來就不是工具，只用了工具
而沒有用到它核心的方法，那跟傳統的方法根本也沒有差別。
也是能做CI，而用了Jenkins也不等於就是CI，很多公司以為用了Jenkins甚至買了幾
套CD或是DevOps的工具就叫在做CI了，事實上CI的重點從來就不是工具，只用了工具
而沒有用到它核心的方法，那跟傳統的方法根本也沒有差別。
CD包括的就更廣，想解決的問題也更全面，然後DevOps則是再拓展到把operation也包
括進來，不過這些就要再花更多篇幅來講了，暫時就先不說了。
Note: 必須要講得更清楚的是，最早的CI其實是Extreme Programming的一部分，當時
只有Test-Driven Development，還沒有pipeline的概念。而很多人做CI就只做半套，
把Test-Driven Development拿掉，就變成好像CI=nightly build。後來在2010年Jez
Humble提出CD的時候，因為他本身就很愛XP，所以將CI拿出來加強，加入了pipeline
跟其他的一些東西，成為了CD的前半段核心部分。所以現在講的CI其實都是CD版本的
CI，並不是當初最原始XP版本的CI了。
只有Test-Driven Development，還沒有pipeline的概念。而很多人做CI就只做半套，
把Test-Driven Development拿掉，就變成好像CI=nightly build。後來在2010年Jez
Humble提出CD的時候，因為他本身就很愛XP，所以將CI拿出來加強，加入了pipeline
跟其他的一些東西，成為了CD的前半段核心部分。所以現在講的CI其實都是CD版本的
CI，並不是當初最原始XP版本的CI了。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 118.165.198.156
※ 編輯: Wolfken 來自: 118.165.198.156 (01/29 14:31)
推 :1F 01/29 14:47
推 :看到認真解釋就該給推了 但CI的部份 能合80%的公司 CODE水準2F 01/29 14:59
→ :在低也有一定水準...(我說穩定度)
→ :在低也有一定水準...(我說穩定度)
推 :推4F 01/29 15:08
推 :推5F 01/29 15:22
推 :推6F 01/29 15:45
推 :原po真好心推7F 01/29 17:26
推 :認真推8F 01/29 17:29
推 :Push9F 01/29 21:07
推 :推10F 01/29 21:24
推 :認真推~11F 01/29 23:51
推 :推~12F 01/30 02:26
推 :推~寫得很不錯13F 01/30 10:51
推 :讚14F 01/30 11:03
推 :推15F 01/30 11:34
推 :推這篇！16F 01/30 16:47
推 :大為解惑 大推17F 01/31 00:04
推 :受教了，感謝原po大分享18F 01/31 22:30
※ 編輯: Wolfken 來自: 118.161.33.79 (01/31 23:55)推 :大推19F 02/10 00:22
推 : 朝聖20F 12/20 21:05
推 : 好像沒看到 DevOps 的定義21F 12/21 22:29
--
作者 Wolfken 的最新發文:
- 最近幾年剛好也加入台灣的硬體廠做軟體 分享一下為什麼一堆硬體廠高喊轉型跨足軟體，煞有其事發新聞稿，大舉徵才數百人 做到現在卻沒一家成功的原因 總結兩個原因，高層認知與決心不足，公司文化不對 首先，軟體 …4F 3推
- 以下都是我夢到的，如有雷同純屬巧合 昨天晚上突然夢到強者我朋友 強者我朋友在一家全球知名科技公司上班 他跟我說該公司幾年前實施了用OpenOffice全面替換Office的策略 從此以後公司內部要買O …26F 10推
![]()
其實應該是因為一轉很容易，二轉很難 一轉的模式很簡單，搭上全球化列車，吸引外資，做代工產業 這種模式在二戰結束開始就是這樣搞，先是日本製造業 然後台灣跟韓國製造業跟後來的電子製造業，接下來中國，接下來 …44F 18推- : : : : 35 其實global職缺不會比較難,只不過面試的內容有很大的不同,面試問的東西也比較多 之前有去面試幾間國外頂尖的公司(FLAG之類的),雖然最後on site沒過關,但是準備的 過 …23F 6推
- 作者本身是藥劑師，工作是研究藥，也有在大學教藥學，所以是有專業知識的 他說根據經驗，Grade 2 strain NBA從來沒有人一個月內回來過，更別說兩星期 要是雷霆隊醫有什麼神奇療法，其他隊隊醫 …65F 36推 1噓
點此顯示更多發文記錄
回列表(←)
分享