- 原文地址：Automate CI/CD and Spend More Time Writing Code
- 原文作者：Cormac Foster
- 譯文出自：掘金翻譯計劃
- 本文永久連結：github.com/xitu/gold-m…
- 譯者：Yong Li
- 校對者：zhaoyi0113，LeviDing
自動化持續整合/持續分發，以節省更多時間編寫程式碼
該文章由 微軟 Visual Studio 應用中心 贊助。請支援我們的合作方，是他們讓 SitePoint 成為可能。
什麼是軟體開發中最棒的部分？編寫漂亮的程式碼。
什麼是最糟的部分？其餘的一切。
開發軟體是一份精彩的工作。你會用全新的方法解決問題，取悅使用者，並且親眼見證你的工作讓生活更美好。然而在我們花費時間編寫程式碼之外，我們常常還要花費同樣多的時間來管理隨之而來的各種瑣碎開銷 —— 這些都是在浪費時間。以下是一些最大的效率黑洞，以及在微軟我們是如何處理這些問題，以幫助你節省一些開發時間。
1. 生成
讓你超讚的應用到達使用者手中的第一步是什麼？讓它出現。許多人可能覺得把原始碼轉換成二進位制檔案，在今天已經不是什麼難事了，但實際上它依然是。取決於專案的不同，你可能一天需要編譯好幾次，或是在不同的平臺上編譯，而這些都佔用了你本可以用來編寫程式碼的寶貴時間。除此之外，如果你在生成 iOS 應用，你還需要 Mac 生成代理，尤其是當你使用跨平臺框架來建立應用時。而這甚至都不一定是你最主要的開發工具。
你想要奪回這些時間，最好的辦法就是自動化（我還會多次重申這點）。你需要將配置和硬體管理都自動化，使得應用需要生成的時候，直接就可以開始生成。
我們對於這一需求的回應就是：Visual Studio 應用中心生成服務。這一服務幫你自動化所有你不想手動重複的步驟，使得你每次提交程式碼的時候，或者無論何時你、你的測試團隊、或者你的釋出經理希望的時候，你都可以快速生成。只要將生成服務連線到 GitHub，BitBucket 或者 VSTS 倉庫，選取一個分支，配置幾個引數，你就可以在雲中生成 Android、UWP 甚至 iOS 和 macOS 應用，而無需管理任何硬體。如果你有更特別的需求，你還可以新增 post-clone、pre-build 以及 post-build 指令碼來進行自定義。
2. 測試
我花了許多年做軟體測試。在我的職業生涯中，以下是我最討厭聽到的三個問題：
“你完成了嗎？”
“你可以重現嗎？”
“真的有這麼糟糕？”
在過去，已經很難有足夠的時間和資源來進行徹底的，像樣的測試。但是移動開發的出現讓這一問題更加惡化。如今我們需要將更多的程式碼更加頻繁地分發到更多的裝置上去，我們不能浪費幾個小時來重現一個神出鬼沒的重大故障，我們也沒有時間來爭論某一個 Bug 是否嚴重到推遲產品釋出時間。然而同時，我們又是最終需要對無法忽視的故障和劣質產品負責的人。作為團隊的成員，我們希望比問題更快一步，來提升質量，而不是讓問題阻礙了釋出。
所以解決之道是什麼？當然是”自動化“。但必須是有意義的自動化。如果你不能整合到一起的話，一張張的資料表和一個個存滿截圖的資料夾就什麼用處也沒有。當你臨近截止日期，而又必須說服產品負責人來打電話中止釋出的時候，你不僅要給出易於他們理解的資訊，同時又要給開發人員保留足夠的細節來供其修復。
為了改善這一問題，我們建立了應用中心測試服務。該服務可以在數以千計的真實裝置上使用數以百計的不同配置來進行自動化 UI 測試。因為測試全部是自動的，每一次都確保執行完全相同的測試，這樣在每一次生成中你都能立刻發現效能問題和 UX 偏差。測試會生成截圖和視訊，也會生成效能資料，這樣任何人都能發現問題，而開發人員也能點進詳細的日誌中，即刻開始修復問題。你還可以在每次程式碼提交時先在個別裝置上做抽查，然後再在數以百計的不同裝置上做迴歸測試，以確保對所有的使用者都一切正常。
3. 分發
你終於完成了一個應用並且它能像預期一樣正常工作，太棒了！但是真正的迭代現在才開始。你想在應用抵達終端使用者之前就知道其他人怎麼看你的應用，但是你要怎麼做呢？建立一個 beta 版本已經足夠難了，而要確保每一個人都有你應用的最新版本（如果是移動應用，甚至要先確保使用者能夠安裝它）簡直要花費你全部的時間，並且你的團隊成員誰都不願意做這樣的工作。
再一次，自動化。當你準備好推送一個版本的時候，你需要自動化的通知流程以及應用分發流程，並且你需要在每一次你生成的時候（或至少釋出經理同意的時候），這兩者都能夠自動觸發。
我們的解決方案是應用中心分發服務。你需要的只是一組郵件地址，就可以把你的版本釋出到內部使用者或 beta 測試使用者的手中。你只需建立一個分發組，上傳你的版本（或者從原始碼倉庫生成），然後分發服務就會處理剩下的一切。如果你覺得這聽起來就像 HockeyApp，你猜對了。應用中心分發服務就是下一代的 HockeyApp，將它的自動化分發功能整合進我們其它的持續整合/持續分發服務之中。一旦你完成了 beta 測試，分發服務就會將你的應用部署到 Google Play，蘋果的 App Store，或者 —— 對於企業使用者來說 —— 微軟的 Intune，從而讓你的應用抵達終端使用者手中。
4. 閉環
人們經常談論部署流水線，但我們不滿足於單向的部署過程。如果你能夠知曉在應用釋出完之後發生了什麼，你就可以把反饋意見告知開發人員，由此形成一個閉環來使你的產品更好、更快。這一反饋資訊以兩種形式存在 —— 關於使用者如何和你的應用進行互動的分析，以及必不可少的，關於應用在何時，發生怎樣的故障的報告。
先說第二點，因為故障很要命。當應用出現故障的時候，雖然你想快速地瞭解情況，但你更需要知道故障到底有多緊要。在一個不起眼的小功能中卻影響到所有人的故障，通常比只有 iPhone 4 使用者完全無法啟動應用，要更嚴重。應用中心的故障服務可以將相似的故障進行分組，並且告知你最受影響的平臺，以使你做出明智的分檢決定。當你準備好開始修復問題的時候，故障已經完全符號化，所有你需要的資訊已經準備就緒。你可以自動地在你的故障跟蹤程式中建立記錄，方便開放人員無需中斷他們的工作流就可以開始修復故障。更多的自動化再一次帶來更多的時間，以編寫更好的程式碼。
對於第一點的分析資料，你通常需要一些開箱即用的工具。應用中心分析服務提供了使用者層面和裝置層面的、側重於參與度的度量應用，這些都是產品負責人最希望見到的。它們可以告訴你諸如：是誰在使用哪些裝置、使用得多頻繁、在哪裡使用、使用多長時間等資訊。當然，你的應用不會和別人的完全一樣，因此你更可以建立和跟蹤自定義的度量，比如“預定了乘車”或者“選擇了配送上門”。如果你需要更深入的分析，我們還支援持續匯出到 Azure Application Insights。
5. 使用手邊的工具開始工作
你可以花費整天的時間來紙上談兵地構想你完美的持續整合/持續分發方案，但是除非你能付諸行動，它分文不值。不管是整合一個你十分偏愛的現有系統（或許你只是不得不用），還是先自動化一些小的手動流程再逐漸改善其它部分，重要的是你能利用手邊可用的工具立即開始行動。
當然，在這裡我的立場是有傾向性的，並且我相信你應該嘗試一下我們的整套系統。不過開發者有著各式各樣的需求。如果你只是想要採用應用中心的部分服務，我們已經把它設計為完全模組化的了。我們為每一個應用中心的服務提供了 REST API，我們也和像 VSTS 之類的服務預先做好了整合。我們相信這才是它應有的樣子，因為是你在建立你的應用，你應該用自己的方式來建立它。
我們歡迎你 試一試 Visual Studio 應用中心，此時它是全新的，並且可以免費開始試用。我們希望聽到你的想法！
掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。