持續交付一——軟體交付的問題

對於作者提到的關於軟體交付的問題，雖然自己沒有太多的經歷，但是從身邊人的闡述中也聽說過關於軟體交付的問題,因為軟體部署交付引起的加班最正常不過了。

書中列出了幾個傳統模式下的軟體部署方式，也就是書中總結的<strong>反模式</strong>：

部署流水線

• 手工部署軟體——手工容易出錯，結果不可預測，重複性高，消耗的人力多，時序問題。
• 開發完成之後才向類生產環境部署——由於其他的外部因素導致運維人員在開發完成甚至釋出到生產環境的時候才第一次見到軟體，釋出週期長，後期維護代價高，在最後期限之前有很少的時間去修復出現的問題。
• 生產環境的手工配置管理——為釋出準備環境時間長，無法回滾到以前的版本叢集中各個節點承擔的負載不同

針對以上的幾點原因，作者也給出了相應的解決方法，從<strong>速度與質量</strong>兩個方面來解決交付過程中出現的問題：

• 速度——減少週期時間
• 質量——以一種高效，快速，可靠的方式交付高質量而且有價值的軟體

為了實現解決問題的方法，我們應該怎麼做呢？

1.自動化——讓本來需要人工做的事情儘可能自動化，構建，部署，測試，釋出一系列的行為自動化，讓這些動作變得可重複，相比手工降低出錯的機率。
2.頻繁做——頻繁釋出，讓每一個版本之間的差異減小，降低釋出的風險，更容易回滾，加快反饋速度。
感覺這一點跟小步提交有一些聯絡，通過小步提交減少程式碼版本之間的差異，也能夠更快的發現程式碼的錯誤在哪裡。發現錯誤之後也能夠很快的回到之前的版本。
將自動化與頻繁做結合起來——頻繁地自動化來說，反饋十分重要，反饋地三個標準很有用：
1.無論什麼樣地修改都應該觸發反饋流程——構成軟體的可執行程式碼，配置資訊，執行環境和資料任何一個部分發生改變都有可能導致軟體行為的變化。
2.反饋應該儘快發出，——我理解的就是出現問題自動化的形式能夠及時反饋，相對於手工的動作更快。編寫測試跟自己手動測試程式碼當然直接點一下執行程式碼看有沒有通過速度更快。
3.交付團隊必須接收反饋，並根據其做出相應地行動——就拿自己寫程式碼的過程來說，通過測試或者是其他的方式發現自己的程式碼存在問題的時候，必須先解決自己目前存在的問題，解決之後才能夠繼續後面的開發。如果將自己的錯誤累計以後再進行修改的話，代價會比及時解決的方式高很多。

小結：
感覺通過自動化的方式能夠幫助我們更快的接收到錯誤資訊的反饋，把錯誤細節話能夠幫助我們更快的意識並解決遇到的問題，與此同時，版本控制工具的使用讓我們在錯誤之後回滾到以前的版本，將二者相結合能夠幫助我們實現一部分的自動化。
團隊之間的合作也至關重要，大家有共同的目標，並在實現目標的過程中互幫互助，持續交流，或許我們能偶在問題出現之前就發現問題呢。對於持續改進，我覺得可能codereview和retro就是兩個結合起來能夠幫助我們實現持續改進，每個人都參與到過程當中，同時不斷的提出問題與反饋，促進大家之間的相互協作，效率應該能夠高很多。