35發(fā)布軟件上線只新開始

35|2019-05-21軟件工程之 進(jìn)入課16:42說到版本發(fā)布，對于很多開發(fā)人員來說，覺得是很簡單的一個(gè)事情，就是將程序編譯打包部署，但實(shí)際發(fā)布的時(shí)候，卻經(jīng)常出現(xiàn)發(fā)布錯(cuò)版本的問題，或者是發(fā)布前修改了一點(diǎn)代碼導(dǎo)致上線出現(xiàn)Bug的情況發(fā)生。而版本發(fā)布對于很多項(xiàng)目管理者來說，又是一個(gè)很糾結(jié)的事情，覺得還有很多功能沒完成，很多Bug還沒改完，害怕用戶負(fù)面評(píng)價(jià)，結(jié)果時(shí)間一拖再拖，遲遲無法上線。在討論這個(gè)話題之前，我們需要了解“版本”的含義。也許你已經(jīng)知道版本的含義，但是這里還是有必要明確一下，因?yàn)樵诓煌恼Z境下，版本的含義也有所不同。比如產(chǎn)品經(jīng)理會(huì)對開發(fā)人員說：“這個(gè)功能我們會(huì)放到下個(gè)版本中實(shí)現(xiàn)”，開發(fā)人員會(huì)對測試人員說：“這個(gè)Bug在昨天的版本中已經(jīng)修復(fù)了”。這里產(chǎn)品經(jīng)理說的“版本”是指特定功能集合，開發(fā)人員說的“版本”是指某一次程序的構(gòu)建結(jié)果。也就是說對軟件版本來說，包含兩部分含義，一部分代表特定功能集合，一部分代表某一次特定的代碼構(gòu)建結(jié)果。比如說：1.2.1、2.0、3.0.1build-123。加主版本號(hào)。修正版本號(hào)則表示功能不變化的情況下修復(fù)Bug，而構(gòu)建版本號(hào)表示一次新地知道應(yīng)該有哪些功能，屬于哪一次的構(gòu)建結(jié)果。在修復(fù)Bug或者增加功能時(shí)，開發(fā)人員也能清楚地知道代碼應(yīng)該加入哪個(gè)版本。在驗(yàn)證Bug時(shí)，測試人員就可以知道應(yīng)該在哪個(gè)版本中驗(yàn)證Bug有沒有被修復(fù)。而實(shí)際上，并不代表你需要完成所有的功能，或者沒有任何Bug，有一個(gè)完美的版本才能上線。畢竟追求完美是沒有止境的，這世界上也不存在完美的軟件，很多著名的軟件，比如indows、Oie、iOS都免不了在發(fā)布后還要打補(bǔ)丁。首先是規(guī)劃好要發(fā)布的功能。在發(fā)布前，搞清楚哪些是用戶必須要有的功能，哪些是用戶可以沒有的功能。對于必須要有的功能，那么要保證軟件中有這個(gè)功能才能發(fā)布，對于不是必需的功能，可以以后再逐步完善。有一個(gè)經(jīng)典的案例就是第一代的iPhone，復(fù)制粘貼的功能都沒有，但是在用戶界面和觸屏然后是定義好發(fā)布的質(zhì)量標(biāo)準(zhǔn)。在發(fā)布前，搞清楚你的用戶對質(zhì)量的容忍度如何，對哪些功能的質(zhì)量要求高，對哪些功能的質(zhì)量要求沒那么高。對于那些用戶在意的功能，要具有較高的發(fā)布標(biāo)準(zhǔn)，反之，則可以有較低的質(zhì)量標(biāo)準(zhǔn)。再有就是要設(shè)計(jì)好發(fā)布的策略?？紤]好是直接發(fā)布給所有用戶？還是先讓一部分用戶試用？比如說可以先讓內(nèi)部用戶使用，內(nèi)部用戶對軟件質(zhì)量問題容忍度是很高的，還可以幫助發(fā)現(xiàn)很多問題。讓一部分用戶使用Beta版也是一個(gè)好的發(fā)布策略，當(dāng)用戶知道你的軟件還是Beta版的時(shí)候，要求會(huì)比較低一點(diǎn)，可以接受一些不那么嚴(yán)重的Bug。還有就是采用灰度測試的發(fā)布GmailBetaiOS，用戶也可以選擇安裝最新的Beta版本，可以先體驗(yàn)新功能，但是必須忍受系統(tǒng)的不穩(wěn)定。最后，就是有一個(gè)綜合性的版本發(fā)布計(jì)劃。在確定了要發(fā)布的功能、定義好了質(zhì)量標(biāo)準(zhǔn)、設(shè)有功能沒完成沒關(guān)系，關(guān)鍵要看這個(gè)功能是不是必須要有；有Bug沒有修復(fù)完成，是不是影響發(fā)布，要看這些Bug是不是影響發(fā)布的質(zhì)量標(biāo)準(zhǔn)；還可以采用一些像Beta版、小規(guī)首先是必須保證要編譯部署的是正確的版本。雖然一般來說，開發(fā)人員不會(huì)犯這樣的錯(cuò)誤，但是如果發(fā)布了錯(cuò)誤的版本，后果可能很嚴(yán)重，所以要引起足夠重視。比如說當(dāng)年拼多多造成了幾千萬損失的薅羊毛事件，就是錯(cuò)誤發(fā)布了一個(gè)測試用的無門檻券，導(dǎo)致被大量濫用。次對代碼的修改，都可能導(dǎo)致新的Bug產(chǎn)生。如果你的代碼庫在發(fā)布之前還一直在增加新的功能或者是不停地修復(fù)Bug，那么質(zhì)量是難以穩(wěn)定下來的。再就是要在發(fā)布失敗后能回滾。沒有誰能保證程序發(fā)布后沒有嚴(yán)重問題，所以最保險(xiǎn)的辦法就是要在部署后，如果發(fā)現(xiàn)發(fā)布的版本出現(xiàn)嚴(yán)重問題，就應(yīng)該對程序進(jìn)行回滾操作，恢復(fù)到部署之前的狀態(tài)。即使有些不可逆的升級(jí)，也需要事先做好應(yīng)對措施，比如發(fā)布公告，停止服務(wù)，盡快修復(fù)。針對這些問題，已經(jīng)有些好的實(shí)踐，比如說代碼凍結(jié)、Bug分級(jí)、回歸測試等可以降低發(fā)布風(fēng)險(xiǎn)，保障發(fā)布產(chǎn)品的質(zhì)量。在《12|流程和規(guī)范：紅綠燈不是約束，而是用來提高效率》這篇文章中，我也提到了：流程和規(guī)范能將好的實(shí)踐標(biāo)準(zhǔn)化流程化，讓大家可以共享經(jīng)驗(yàn)。所以在版本發(fā)布上，我們也可以制定合理的流程，來應(yīng)用這些好的實(shí)踐，保證發(fā)布的質(zhì)量。什么是代碼凍結(jié)呢？就是在發(fā)布之前，對于要發(fā)布的版本，在源代碼管理工具中，專門創(chuàng)建一個(gè)eleae分支，然后對于這個(gè)分支的代碼，凍結(jié)功能的修改，不接受新功能的增加，甚至重要性不高的Bug都不修改，只修復(fù)重要的Bug。對代碼凍結(jié)后發(fā)現(xiàn)的Bug要分級(jí)BugBug。代碼凍結(jié)的原則就是盡可能減少代碼的修改，避免引起不穩(wěn)定。所以對于這些Bug，要有一個(gè)簡單的分至于如何對一個(gè)Bug每次修復(fù)Bug后，發(fā)布新的候選版本進(jìn)入代碼凍結(jié)后，開發(fā)人員還需要對一些Bug進(jìn)行修復(fù)，每一次修復(fù)完Bug后，就要生成一個(gè)新的候選發(fā)布版本，比如說1.1RC1、1.1RC2。關(guān)于生成發(fā)布版本，現(xiàn)在比較流行的做法是和持續(xù)集成系統(tǒng)整合，完全自動(dòng)化。也就是在自動(dòng)化測試通過之后，會(huì)自動(dòng)構(gòu)建，生成各個(gè)環(huán)境的發(fā)布版本。這樣好處是，可以避免人為失誤導(dǎo)致的錯(cuò)誤，另外程序的配置管理做好了的話，只要測試環(huán)境的版本在測試環(huán)境測試沒問題，那么就可以認(rèn)為在生產(chǎn)環(huán)境的版本也是正常的。自動(dòng)化構(gòu)建，生成發(fā)布版本并不復(fù)雜，各個(gè)語言都有成熟的方案，如果你還不了解的話，可以通過搜索引擎搜索關(guān)鍵字：“[對應(yīng)平臺(tái)]自動(dòng)打包”，例如搜索“iOS自動(dòng)打包”、“iOSbuildautomation”其中稍微有點(diǎn)麻煩的就是如何應(yīng)用不同環(huán)境下的不同配置，比如說測試環(huán)境連測試環(huán)境服務(wù)器，生產(chǎn)環(huán)境連生產(chǎn)環(huán)境服務(wù)器。有關(guān)程序配置管理部分，可以參考這篇文章：《大型項(xiàng)目程序配置管理演化之路》Bug修復(fù)完，對主要流程要重新測試一遍，同時(shí)還要對之前確認(rèn)過的Bug再確認(rèn)一遍，以確保Bug確實(shí)修復(fù)了，并且沒有引入新的Bug。上線發(fā)布是一件很嚴(yán)謹(jǐn)?shù)氖?，所以在正式上線發(fā)布前，通常還需要有一個(gè)申請和審批的流程。審批的主要目的是要有人或者有部門統(tǒng)籌對所有的上線發(fā)布有一個(gè)全面的了解和控制，避免上線過于隨意導(dǎo)致問題，避免和其他部門的上線沖突。如果已經(jīng)實(shí)現(xiàn)了自動(dòng)化，部署發(fā)布應(yīng)該是非常簡單的一步。如果還沒有自動(dòng)化部署發(fā)布，也需要事先將詳細(xì)的操作步驟寫下來，避免部署發(fā)布時(shí)發(fā)生紕漏，這樣在實(shí)際部署發(fā)布時(shí)，按照事先寫好的步驟操作就不容易出現(xiàn)錯(cuò)誤。正常。如果做好了數(shù)據(jù)監(jiān)控，還同時(shí)要對一些關(guān)鍵數(shù)據(jù)進(jìn)行監(jiān)控，例如服務(wù)器CPU利用如果萬一發(fā)現(xiàn)版本上線后出現(xiàn)問題，需要考慮按照事先準(zhǔn)備好的回滾方案進(jìn)行回滾操作，盡量將損失降到最低。通常不到萬不得已，不建議馬上對問題打補(bǔ)丁進(jìn)行修復(fù)。因?yàn)槟呐潞苄〉拇a修改，都可能會(huì)引入新的Bug。而重新做一遍回歸測試，耗時(shí)會(huì)比較長。用戶在使用你的產(chǎn)品的時(shí)候，可能會(huì)遇到一些Bug或者是有一些建議，所以需要給用戶反饋的渠道，讓用戶可以有途徑對于Bug或者功能去反饋。通過收集用戶的反饋，可以進(jìn)一AppCrash的Log、監(jiān)控服務(wù)器資源占用情況、監(jiān)控API出錯(cuò)的比例、監(jiān)控網(wǎng)頁響應(yīng)的速現(xiàn)和定位產(chǎn)品問題？》中繼續(xù)帶你一起學(xué)習(xí)。不管怎么樣，軟件成功上線了都是一件值得祝賀的事情，同時(shí)也是時(shí)候回顧總結(jié)一下整個(gè)項(xiàng)目過程了，關(guān)于這一點(diǎn)，我也會(huì)在后續(xù)專欄文章《項(xiàng)目總結(jié)：做好項(xiàng)目復(fù)盤，把經(jīng)驗(yàn)變成能力》中跟你一起探討如何做好項(xiàng)目總結(jié)復(fù)盤，把經(jīng)驗(yàn)變成能力。版本規(guī)劃，其實(shí)就是通過合理的規(guī)劃，盡可能的讓軟件的功能和質(zhì)量，滿足好用戶的預(yù)期。所以一方面要盡可能提供應(yīng)有的功能和保證質(zhì)量，另一方面也可以通過合理的發(fā)布策略，例如eta測試，降低用戶預(yù)期。通過規(guī)范的發(fā)布流程，可以確保要發(fā)布的版本正確以及發(fā)布質(zhì)量的穩(wěn)定。流程的關(guān)鍵在于發(fā)布前要對代碼凍結(jié)，避免發(fā)布前頻繁修改代碼引入新的Bug，同時(shí)在每次修復(fù)Bug后，要做回歸測試保證Bug被修復(fù)以及沒有引入新的Bug，上線后還要對線上版本再一次測試，確保沒有問題。整個(gè)流程中一些手工部署發(fā)布的操作應(yīng)該盡可能自動(dòng)化。你在發(fā)布版本前，會(huì)做哪些準(zhǔn)備工作？你的發(fā)布流程是什么樣的？通過