以前認為在一個軟件開發(fā)過程中,代碼寫完了重頭戲就過去了,可能真的是因為沒有經(jīng)歷過從軟件開發(fā)完成到交付給客戶的這個過程,恰好最近我們的課程設計編碼已經(jīng)完成,正在考慮部署交付的問題,拿起這本書算是比較合時宜吧!
這本書關(guān)注的點是構(gòu)建,部署,測試和發(fā)布過程,中心模式是部署流水線,即就是一個軟件從構(gòu)建,部署,測試到發(fā)布的自動化實現(xiàn).
發(fā)布反模式
- 手工部署軟件:人并非機器,很難避免一些人為操作的失誤,更別說執(zhí)行順序和時機也會引起一些意料之外的后果.
- 開發(fā)完成之后才向類生產(chǎn)環(huán)境部署:當大家都以為軟件開發(fā)完成大時候殊不知運維人員可能是第一次見到這個軟件,或者測試環(huán)境和之前的開發(fā)環(huán)境大不相同等等各種問題.
- 生產(chǎn)環(huán)境的手工配置管理:每次準備運行環(huán)境都需要巨長的時間,多次部署到試運行環(huán)境都很成功,但一到生產(chǎn)環(huán)境就失敗等等.
如何做得更好
頻繁且自動化的發(fā)布軟件
- 每次修改都應該觸發(fā)反饋流程:任何部分的修改可能都是牽一發(fā)而動全身,所以每一次的修改應當觸發(fā)全面而又自動化的測試.
- 盡快接收反饋:整個流水線的提交階段的測試和提交階段之后的測試是不同的.------------不太理解
- 交付團隊應當根據(jù)反饋做出反應:將反饋的過程以及結(jié)果可視化,及時更新,要讓團隊的每個人都能注意到并且意識到它的重要性.才會做出想應的調(diào)整.
何時為可發(fā)布版本
并不是你說你準備好了一切軟件才可發(fā)布,客戶隨時想要驗收成果,代碼庫中的代碼都應當是可發(fā)布版本,對于可發(fā)布版本,我的理解是可以不完整,但不能出現(xiàn)bug.
所以每一次的提交都應當是可以被發(fā)布的,提交需謹慎.
軟件交付的原則
-
將幾乎所有事情自動化
只有通過自動化很多事情才能是可控的,也只有更廣泛地實現(xiàn)自動化,寶貴的人力才能被解放出來做更有價值的事情. -
把所有東西都納入版本控制
這樣做的目的是將開發(fā)人員在開發(fā)過程中自動達成的某種不成文的規(guī)定或者說某種默契可視化出來,讓一個第一次見到這個軟件的人也能規(guī)范正確地去運行整個程序. -
提前并頻繁地做讓你感到痛苦的事
這條原則我覺得對于很多事都是適用的,在軟件交付領(lǐng)域它當然是一條不可撼動的原則,比如從一開始就加入測試,從一開始就頻繁地集成,從一開始就做到小步提交,這些看似煩人的條條框框?qū)嶋H上卻讓后邊的路越來越平坦. -
內(nèi)建質(zhì)量
越早發(fā)現(xiàn)bug,修復的成本就越低,這也很好地解釋了上一條原則. -
'DONE'意味著已發(fā)布
沒有快完成或者完成了百分之多少這種說法,只有完成或者未完成,只要沒有發(fā)布,就是未完成,因為在沒有發(fā)布時,你永遠不知道后邊還有百分之多少的事情等著你去做. -
交付過程是每個成員的責任
我認為這條原則更多地時說團隊合作集體意識吧,一旦一個團隊形成,那么榮辱共享,做得好是所有人的功勞,出現(xiàn)意外也不能急著指責某一個人,大家一定是有同一個目標的. -
持續(xù)改進
這條原則很熟悉啊,團隊成員定期做retro,保持做得好的地方,改進有缺陷的地方,并且每個改進都要指定一個owner,由他負責跟進.是我們也一直在做的事情,個人覺得將任何一個改進點都分配到個人真得是非常重要.
今天才知道原來這就是戴明環(huán):計劃-執(zhí)行-檢查-處理.
