讓我們談談持續集成。是的，我的意思是“持續集成”，而不是“持續交付”。
在小型迭代代碼檢查中的敏捷技術，以及應對大的代碼群所進行的測試，這些之中的持續集成是一項長期的開發實踐。但是隨著軟件專業人士開始關注持續交付，持續集成就漸漸被漠視了。
與其一直在尋找最佳的實踐，軟件專業人士還不如繼續看好持續集成。他們已經這樣做很久了，他們不會質疑這么做是否正確。最近的一次對話中，Coveros的CEO以及軟件開發咨詢顧問Jeffery Payne告訴我說，這個方法是錯誤的。
持續集成：并不是在構建那么簡單
Payne說，當軟件專業人士討論持續集成時，大部都是關于自動化構建流程。“構建是他們對完成的定義。”但是構建只是戰役的一半。成功的構建告訴你，從字面上說，就是把代碼團結在一起，他解釋說。“這并不代表這就中代碼的工作方式。”持續集成實踐還應該包含自動部署代碼到他們所在的平臺，Payne說。“你一定要確保它的配置是正確的，且所有集成問題已經得到解決。”
確保持續集成還包括自動部署，而不是廣泛概括了持續交付的策略，這是一個實用的方法，因為這樣做是對的，種什么因，得什么果，Payne說。“當你開始持續集成時，你就給持續交付設立了一個舞臺。不你的持續集成實踐是良好的，強壯的時，持續交付就是下一個邏輯步驟了。”
在我們對話中，Payne還談了他對持續集成、持續交付、自動測試作為大型 DevOps環境的一部分的看法。這一對話中，他分享他的一些觀點，“為什么DevOps改變了一切，”這是他將要在2015年6月的Agile Development Conference West上分分享的。
一切都是為了代碼
當持續集成把部署環境考慮進去時，實際來說，軟件團隊要創建一個環境，即Payne說到的“一切都是為了代碼。”換句話說，支持代碼的基礎設施要部署，而不只是應用程序本身，以表示為代碼。
DevOps方法可提早對問題進行檢測，而這在之前只能在開發后期才可以。“你能夠知道代碼是如何集成到它的平臺中的，” Payne說。另外，DevOps 讓QA和測試更高效。“如果你在云端設置了一個虛擬化測試環境，測試人員不必再依靠運營人員來設置測試環境，”他說。“你可以控制一切”關于配置的事情。這是與傳統方法最大的不同，即只有源碼可控，Payne說。“你不得不返回，查出發生了什么事情。”
這樣，讓我們了解你的想法。你的持續集成實踐包括DevOps嗎?還是，你只局限在自動構建領域?你是否在做持續交付?如果是，你的集成流程工作如何?
京公網安備 11010502049343號