上周二，我作為持續討論（＃c9d9）的一部分，參加了一個關于Build Automation主題的在線討論會，這是一系列有關敏捷，持續交付和DevOps的社區討論會。 自動化構建流程面臨許多挑戰，包括第三方依賴關系，構建版本管理，尤其是文化，小組成員討論了解決這些挑戰的現實經驗。

持續討論是Electric Cloud的一項社區計劃，該計劃通過自動化其構建，測試和部署過程來推動SpaceX，Cisco，GE和E * TRADE等企業的持續交付。

以下是我對面板所做的貢獻。

構建瓶頸對您的管道意味著什么？

以我的經驗，瓶頸通常與軟件架構有關，而與工具和團隊無關。 我認為大多數人還沒有準備好以可以快速，輕松地構建，測試和部署軟件的方式來設計軟件。

我們需要開始將事情分解成非常小的部分。 這是消除瓶頸的最簡單方法。 大是壞，小是好。 如果我們想要快速交付而沒有停機時間，并且能夠在出現問題時回滾，并且如果我們想經常這樣做，那么我們就需要以一種可以立即交付變更內容而不是整個系統的方式來設計軟件。 使用Docker的微服務和容器打開了新的大門，直到最近我們才對我們大多數人關閉。

長期以來，我們一直試圖圍繞整體架構構建管道，現在是時候以支持持續交付的方式開始構建架構。

有哪些常見問題？

問題是有團隊，但沒有個人責任。 Docker和微服務改變了世界，這使我有可能對我所做的一切負全部責任，而不是將其傳遞給運營商，測試人員和其他團隊。 當將其傳遞給其他團隊時，DevOps的工作只是確保已構建存儲庫，并且構建已投入生產。 DevOps不會決定要構建什么或如何構建。 他們只是將一切推向生產。 這很困難，因為出了問題，人們就不再承擔責任。 要解決此問題，我們需要將軟件分解為小單元。

許多組織正在轉向微服務。 當一切都變小時，可以每天進行部署。 只要您的架構不會阻止它，并且只要您的團隊有能力完成這項工作即可。 如果您需要依靠他人來完成工作，那么就會遇到瓶頸。

我們需要力量掌握在開發人員手中。 該組織的所有其他成員應支持發展。 一旦我們改變了這種文化，事情就會變得更加順利，運行得更快。

您如何看待流程的一致性和標準化？

如果標準化不是最大的創新殺手，那將是很棒的。 標準化后，您將陷入困境多年。

對于嘗試新方法的人們，我認為沒有任何問題，特別是如果您將應用程序分解成小塊的話。 您只需很少的代碼就可以在系統的一小部分進行嘗試。 學習起來并不難。 在我曾任職的任何組織中，標準化程度越高，變更和創新的引入就越少。 以我的經驗，標準化與創新成反比。

一些標準化很重要，尤其是關于如何從外部接收通信時。 但是在團隊中，假設團隊規模合理，沒有人比團隊本身更適合決定團隊的工作方式。

無論我們在做什么，我們都必須在有關組件之間通信的合同上非常嚴格。 但是我開發的組件內部發生的一切都是我的問題，只要沒有外界的干擾太多，我就可以以最好的方式解決它。”

翻譯自: https://www.javacodegeeks.com/2015/05/build-automation-panel.html

總結

以上是生活随笔為你收集整理的构建自动化面板的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。