Re: [請益] 這些軟體工程的方法在台灣的普及度?

看板Soft_Job作者Wolfken時間12年前 (2014/01/29 14:30)推噓20(20推 0噓 1→)

留言21則, 20人參與討論串2/3 (看更多)

※ 引述《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也包括進來，不過這些就要再花更多篇幅來講了，暫時就先不說了。 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了。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 118.165.198.156 ※ 編輯: Wolfken 來自: 118.165.198.156 (01/29 14:31)

推

ohb

01/29 14:47, , 1^F

01/29 14:47, 1^F

推

bndan

01/29 14:59, , 2^F

01/29 14:59, 2^F

→

bndan

01/29 15:00, , 3^F

01/29 15:00, 3^F