GitHub免費支持CI/CD了，開發(fā)測試部署高度自動化，支持各種語言，網(wǎng)友：第三方?jīng)鰶?/h1>

栗子 郭一璞 2019-08-12 14:26:36 來源：量子位

又是大一統(tǒng)

郭一璞 栗子 發(fā)自 凹非寺

量子位 出品 | 公眾號 QbitAI

GitHub激動地宣布，終于支持CI/CD了。

CI\CD，全稱：持續(xù)集成 (Continuous Integration) ，持續(xù)部署 (Continuous Deployment) ，是開發(fā)流程的自動化利器，如今可以在公有項目上免費使用了。

全面兼容各種操作系統(tǒng)，各種語言，以及各種云。

這次重大更新，發(fā)生在代碼運行平臺GitHub Actions身上。

Actions的角色，是把工作流自動化 (變成代碼) ，讓大家在GitHub服務(wù)器上直接測試代碼、部署代碼。

而內(nèi)置了CI/CD之后，這個一條龍的開發(fā)者服務(wù)又進(jìn)化了。

現(xiàn)在，已經(jīng)有Beta版可以注冊試用，正式版也會在11月到來。

消息一出，程序員的世界熱火朝天。推特贊數(shù)1400+，Hacker News熱度也超過了500。

一面，是懷著喜悅迎接一個更強大的GitHub；

一面，微軟這一統(tǒng)天下的姿勢，也讓人感覺到，像CircleCI這樣的持續(xù)集成工具，可能要涼。就像之前發(fā)布的包管理工具，令NPM瑟瑟發(fā)抖那樣。

所以，支持了CI/CD的Actions，到底有多強？

海納百川，高度自動

按官方博客的說法，新的GitHub Actions能把搭建、測試、部署項目的整個流程，更加方便地自動化。

不管你用的是Linux、MacOS還是Windows。

也不管工作流是直接在容器上運行，還是在虛擬機上運行。

廣泛支持各種語言和框架：

Node.js，Python，Java，PHP，Ruby，C/C++，.NET，Android以及iOS。

如果，你想測試多容器的復(fù)雜應(yīng)用，現(xiàn)在可以把你的網(wǎng)絡(luò)服務(wù)和數(shù)據(jù)庫一起測試。只要在工作流文件里，加上一些docker-compose就行了。

然后，詳細(xì)觀察一下功能：

矩陣構(gòu)建?(Matrix Builds)

有了它，你可以把一個項目的許多版本并行測試。

只要在Actions YAML文件里，加上這幾行代碼：

 1jobs:
 2 test:
 3 name: Test on node ${{ matrix.node_version }} and ${{ matrix.os }}
 4 runs-on: ${{ matrix.os }}
 5 strategy:
 6 matrix:
 7 node_version: [8, 10, 12]
 8 os: [ubuntu-latest, windows-latest, macos-latest]
 9
10 steps:
11 - uses: actions/checkout@v1
12
13 - name: Use Node.js ${{ matrix.node_version }}
14 uses: actions/setup-node@v1
15 with:
16 version: ${{ matrix.node_version }}
17
18 - name: npm install, build and test
19 run: |
20 npm install
21 npm run build --if-present
22 npm test

剩下的工作，交給GitHub就可以了。

實時日志?(Live Logs)

實時日志，可以在你的builds運行過程中，為它們的進(jìn)程 (Progress) 提供豐富的反饋。

系統(tǒng)會把你的日志傳輸?shù)紸ctions控制臺，實時顯示狀態(tài)。

這個日志功能是為了易讀性而定制的，里面還有Emoji。

另外，你也可以用一個簡單的永久鏈接 (Permalink) ，來深度鏈接 (Deep Link) 到任何日志文件的任意一行。

這樣，就很容易和小伙伴討論一個故障，或者測試結(jié)果了。

像寫代碼那樣

action就是代碼。所以可以編輯，可以重復(fù)使用，可以分享，可以fork。

當(dāng)你fork了一個項目，就同時fork了它的action，和它的源碼。

這是個無縫連接的方法，你可以用跟原始項目同樣的action來搭建、測試自己的項目。

團隊說，要向社區(qū)學(xué)習(xí)，這是一個很好的辦法。你有了喜歡的項目，重現(xiàn)它的每一步，然后fork過來適應(yīng)自己的需要。

這里用了一種整潔的新語法 (Syntax) 來表達(dá)工作流，基于YAML。

你可以重復(fù)使用每個action和工作流，引用起來很容易，就像簡單的repo reference。

這樣，就可以輕松把它們拼接起來，變成強大的工作流。

可以用JavaScript寫出來，或者創(chuàng)建一個容器action，兩種方法都能通過GitHub API來交互，其他公開API也可以。

還有一個豐富的生態(tài)，可以重復(fù)利用，它來自GitHub的各路合作伙伴：比如LaunchDarkly、mabl、Code Climate、GitKraden。

甚至，你還可以觸發(fā)一個CircleCI上的build。

不止一種工作流

除了構(gòu)建、測試、部署應(yīng)用，你也可以用GitHub Actions來自動化其他任務(wù)：

比如，Issue的分類和管理，自動發(fā)布新版本，和你的用戶群協(xié)作等等。

在GitHub整個開發(fā)者周期里、任何一個事件上面，工作流都能被觸發(fā)。

并且，任何GitHub App都可以添加自定義事件。這樣，開發(fā)者和它們的伙伴，就能定制GitHub來滿足項目的需求了。

從集成包和容器注冊表上構(gòu)建

包的發(fā)布和容器的發(fā)布，是CI/CD工作流上的關(guān)鍵部分。

比如開源一個庫，比如部署一個大型網(wǎng)絡(luò)服務(wù)。

GitHub Actions讓各種包的發(fā)布和使用，變得更容易了。

不管是GitHub Package Registry里面的包，還是其他注冊表里的包。

開發(fā)者能訪問Actions了，也就能訪問GitHub Package Registry，來自動化整個工作流，從構(gòu)建到部署。

簡單上手

GitHub想讓你快點用上CI/CD功能。

于是，一旦你給項目啟用了Actions，GitHub就會根據(jù)你的項目，匹配一些合適的工作流推薦出來。

所有公開項目都可以免費使用。

而私有項目要用CI/CD，就有價格表了：

不過，現(xiàn)在是beta期間，一切都是免費的，快來注冊：

https://github.com/features/actions

至于企業(yè)版，團隊計劃明年推出。

CI/CD是到底是什么

看到這里，可能還有一些朋友沒有明白：

CI/CD到底是個啥？

CI：Continuous Integration，持續(xù)集成，指的是一個團隊的所有開發(fā)人員每天多次把自己手里的代碼合并到主干中去，用一致的自動化方法來構(gòu)建、打包和測試程序，可以頻繁修改代碼，提升軟件質(zhì)量，便于團隊協(xié)作。

CI可以實現(xiàn)自動化測試，更早拿到測試結(jié)果，防止有問題的代碼被交付出去，也更容易編譯，降低了測試成本和和時間。

CD則有兩個概念，一個是Continuous Delivery，持續(xù)交付，在CI中構(gòu)建自動化的測試流程后，持續(xù)將代碼發(fā)布的存儲庫，不一定部署到生產(chǎn)環(huán)境中。

持續(xù)交付對于細(xì)微的變更十分有用，可以加速迭代過程。

另一個是Continuous Deployment，持續(xù)部署，通過自動化的構(gòu)建、測試和部署循環(huán)來快速交付高質(zhì)量的產(chǎn)品，直接部署到生產(chǎn)環(huán)境中，用戶可以感受到產(chǎn)品的變化，不需要做專門的發(fā)布更新，而是修改之后幾分鐘就上線了。

持續(xù)部署可以使發(fā)布頻率更高，每次提交自動觸發(fā)發(fā)布流，降低了小批量發(fā)布的風(fēng)險，用戶體驗也能持續(xù)提升，不用每次都等更新。

議論紛紛

原本要靠第三方才能實現(xiàn)的功能，現(xiàn)在GitHub自己就干了，這當(dāng)然引來了許多程序員的熱烈歡迎，沒多久，GitHub推特的評論區(qū)里歡呼聲此起彼伏：Awesome! Cool! Amazing!

之前那些CI工具，可能日子就不好過了。

一大批CI工具面臨涼涼

不過，既然GitHub自己出了CI/CD功能，那么以前那些第三方CI工具，大家還會用么？

不少人已經(jīng)開始揮手拜別了：

也有人看到多系統(tǒng)支持這一點就非常high:

哇哦，支持MacOS？這一點就足夠我從CircleCI遷移過去了，40美元一個月的CircleCI，對于一些React Native應(yīng)用CI/CD是足夠了，但CD只能一個星期一次。

TravisCI、CircleCI這些工具，可能要面臨用戶流失糟糕狀況了。比如Hacker News上的這位CircleCI用戶：

對我來說這很有趣，讓我想到壟斷的自然崛起和技術(shù)中的多元文化。GitHub最近仿佛要“吃掉整個世界”，比如之前的軟件包管理，給了Artifactory也Nexus不小的撼動。現(xiàn)在搞這個，可能對CircleCI是個壞消息（我是CircleCI的用戶）。

作為一名開發(fā)者，短期來看我確實喜歡這個，不用再東拼西湊那么多東西，頭疼如何把它們整合在一起，如果GitHub不行了，CircleCI也不能用了，我們只要把氣全撒在GitHub頭上就好咯。

但是長遠(yuǎn)來看，這樣競爭環(huán)境就出問題了，作為一個創(chuàng)業(yè)公司員工，要是有大平臺的大廠跑來跟你競爭這是很難搞的事，即使你產(chǎn)品更好，也敵不過大平臺的力量，畢竟他們集成了更多價值。

微軟的野心：把GitHub用戶導(dǎo)流到Azure？

也有人懷疑，此舉是微軟在給Azure鋪路，借GitHub的用戶量導(dǎo)流，目標(biāo)還是瞄準(zhǔn)了云計算市場。

作為一個.NET開發(fā)者，這就像吸引更多人去用Azure DevOps，進(jìn)而讓他們成為Azure云的用戶，這是最后一步，終究是為了擴大云計算的市場。

我覺得對微軟來說一個好的策略是讓GitHub的CI/CD代碼和Azure DevOps盡可能重復(fù)，Azure DevOps不需要這么靈活，只要保持魯棒性就好了，GitHub可以當(dāng)一個試驗場。

所有的路都導(dǎo)向Azure，GitHub的用戶基礎(chǔ)比Azure大得多，微軟想給自家IaaS獲取更多用戶。

估計在GitHub Actions里搞CI/CD的下一步就是讓GitHub能自己跑產(chǎn)品代碼，這樣買Azure云服務(wù)就省去了很多步驟。在一個地方運行代碼，停掉再用一個單獨的工具組件是很隨意的事，在一個地方有整個套件在這個市場是很明顯的事。

所以，你怎么看呢？

—?完?—