91超碰碰碰碰久久久久久综合_超碰av人澡人澡人澡人澡人掠_国产黄大片在线观看画质优化_txt小说免费全本

溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

敏捷軟件開發實踐-Release Process/Release Plan

發布時間:2020-07-20 09:51:02 來源:網絡 閱讀:1790 作者:charles_wang888 欄目:軟件技術

介紹:

因為我們的開發周期是迭代進行的,以Sprint為單位,我們每個Sprint如何去和客戶說我們的成果呢,那么我就需要Demo和release一些新功能,或者一些bug fixing。Demo我這里不討論了, 大體上就是部署都服務器上然后運行下給meeting的所有人看下,我們這里主要討論和發布(release)有關的話題。


實現方式:

話題1:我們如何讓發布者知道我們這個Sprint做的功能?因為就像jdk一樣,它的每次大的release和小的release都有一些評注來說明他們這次發布有哪些功能,或者哪些修正,我們一樣,我們的做法是:

在每個Sprint的結束日,如果對項目有任何變更(功能改變/修正) ,都會在項目中加一個release note.

具體的做法是:我們采用了maven-site-plugin,然后每次我們都會更新site folder,在site.xml中加一個條目到"Release Notes"中:

敏捷軟件開發實踐-Release Process/Release Plan

然后我們加一個apt文件,并且在其中加上release notes

敏捷軟件開發實踐-Release Process/Release Plan

現在我們用mvn site,就可以顯示這些我們寫入的release notes 了。


話題2:選擇合理的release plan

我們何時去release artifact,這是一個很困難的問題。也許有人想簡單了,這不就是把版本號升級下,然后build一下不就完事了么?你差的遠呢。 因為你要發布一個項目,不是操作那么簡單,你必須對于這個項目的質量有很嚴格的把關,也就是說你要確保它的正確性,所以我們必須先把產品在某些環境上做Regression ,如果Regression沒問題,我們還要往更高層的環境上做Regression ,直到幾個環境的Regression 都沒問題了,我們才可以放心大膽的去Release. 具體說,我們有4套環境,分別是Dev,  DevInt,QA ,Production,我們必須一層層往上走,都沒問題了,我們才可以最后的Release并且發布都Production環境中。那么問題來了,因為Release要動代碼倉庫,而我們的開發是迭代進行的并且是時刻不停的,如果Release團隊發布項目時候開發人員又對同一個倉庫提交了代碼,就會導致代碼的不一致性導致發布失敗。我們現在也沒有嚴格的code freeze制度,因為這種制度多半是在瀑布模型中的,我們的開發不能停,那么如何選擇恰當的Release時間點呢?這就是Release Plan要解決的問題。


這個問題很復雜,當時我應邀去設計Release Plan時候,我足足想了2天才拿出一個合理的方案,這里毫無保留的共享下,具體結構如下:

敏捷軟件開發實踐-Release Process/Release Plan

這張圖中,×××的狀態條代表了開發團隊,綠色的狀態條代表了測試團隊,在每個Sprint中,我吧10天分成了N+1到N+10,其中N代表在第N個Sprint,藍色文字代表開發團隊的動作,紫色文字代表測試團隊的動作,紅色文字代表release的人的動作。


所以從上圖不難發現,對于開發團隊來說,他們的主要開發日期是從(N+3)到(N+9),一共7天,這七天他們做開發,所以會去碰代碼倉庫,而對于前2天(N+1),(N+2)和最后一天(N+10),他們都是做一些和代碼無關的事情,所以不會去影響到代碼倉庫。所以我的建議是,讓release的人在Dev和DevInt上做release和Regression的時間控制在(N+1)和(N+2),因為這兩天代碼倉庫的穩定性是可以保證的,然后當開發人員從N+3開始提交代碼后,releaser做QA和Production環境的release和regression,這樣不會影響開發團隊提交代碼。


風險和經驗分享:

其實最大的風險是對于開發團隊,萬一API或者UX Spec不是很明確,或者不穩定,這樣他們的開發時間就會推遲,也許不一定從(N+3)開始了,對于這些情況,我的建議是,如果在(N+1)天遇到了這些各種開發的不利因素,那么盡可能在(N+3)之前全部解決,如果能解決,那么最好,如果不能解決,那么scrum master可以砍掉一些story,這樣至少可以保證開發團隊的按時交付。

還有,就是萬一release失敗了怎么處理?我的建議是:如果release或者regression失敗了,那么代碼會返回到開發團隊的手里,然后變成一個urgent fix 的活動。如果開發團隊足夠給力,他們可以在N+1就解決了,那么萬事大吉,如果到N+2才解決,那么開發團隊就要推遲一天開發,從N+4到N+9,這就需要他們適當提高效率,事實上我們在工作量預估時候也都加了很多buffer時間。如果到N+3了還沒解決,那么releaser就停止release,并且宣告N-1迭代的release 失敗,然后等2星期再進行新一輪的release. 只有這樣,才能保證整個流程的順暢。


總結:

Release是一個非常重要的步驟,我們必須把好這一關。

(1)Release的過程我們可以用release插件并且加好足夠詳細的notes方便以后去追蹤項目的演化。

(2)設計一個非常行之有效的release plan非常重要,關鍵立足點是各種角色之間要不交叉,不相互block,沒有plan的release會讓項目弄的一團糟。

向AI問一下細節

免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。

AI

灯塔市| 德州市| 西乌珠穆沁旗| 延长县| 青铜峡市| 博客| 庄浪县| 徐闻县| 石林| 安阳县| 奎屯市| 武隆县| 东辽县| 华亭县| 马鞍山市| 织金县| 静安区| 南木林县| 溧水县| 阳朔县| 城固县| 同心县| 新沂市| 宝应县| 浙江省| 淮南市| 竹山县| 庐江县| 通江县| 安阳县| 邹城市| 宁远县| 崇明县| 木兰县| 汤原县| 常山县| 唐海县| 宜宾县| 伊春市| 拉孜县| 福州市|