本地構(gòu)建和自動化構(gòu)建

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

持續(xù)討論是Electric Cloud的一項社區(qū)計劃，該計劃通過自動化其構(gòu)建，測試和部署流程來推動SpaceX，Cisco，GE和E * TRADE等企業(yè)的持續(xù)交付。

以下是我對面板所做的貢獻(xiàn)。

構(gòu)建瓶頸對您的管道意味著什么？

以我的經(jīng)驗，瓶頸通常與軟件架構(gòu)有關(guān)，而與工具和團(tuán)隊無關(guān)。 我認(rèn)為大多數(shù)人還沒有準(zhǔn)備好以可以快速，輕松地構(gòu)建，測試和部署軟件的方式來設(shè)計軟件。

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

長期以來，我們試圖圍繞整體架構(gòu)構(gòu)建管道，現(xiàn)在是時候以支持持續(xù)交付的方式開始構(gòu)建架構(gòu)。

有哪些常見問題？

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

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

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

您如何看待流程的一致性和標(biāo)準(zhǔn)化？

如果標(biāo)準(zhǔn)化不是最大的創(chuàng)新殺手，那將是很棒的。 標(biāo)準(zhǔn)化后，您將陷入困境多年。

對于嘗試新方法的人們來說，我認(rèn)為沒有任何問題，特別是如果您將應(yīng)用程序分解成小塊的話。 您只需很少的代碼就可以在系統(tǒng)的一小部分進(jìn)行嘗試。 學(xué)習(xí)起來并不難。 在我曾任職的任何組織中，標(biāo)準(zhǔn)化程度越高，變更和創(chuàng)新的引入就越少。 以我的經(jīng)驗，標(biāo)準(zhǔn)化與創(chuàng)新成反比。

一些標(biāo)準(zhǔn)化很重要，尤其是關(guān)于如何從外部接收通信時。 但是在團(tuán)隊中，假設(shè)團(tuán)隊規(guī)模合理，沒有人比團(tuán)隊本身更適合決定團(tuán)隊的工作方式。

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

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

本地構(gòu)建和自動化構(gòu)建

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。