[譯] 自動化持續集成/持續分發，以節省更多時間編寫代碼

• 原文地址：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、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。