版本控制是軟硬體研發的骨架,想要發展出一顆枝繁葉茂的知識樹,需要根據自己的研發產品屬性,選用合適的軟體+管理方法。
版本是一種稱謂,用於描述同一事物的相互之間有差異的各種形式、狀態或內容。
版本控制(英語:Version control)是維護工程藍圖的標準做法,能追蹤工程藍圖從誕生一直到定案的過程。此外,版本控制也是一種軟件工程技巧,藉此能在軟件開發的過程中,確保由不同人所編輯的同一程序文件都得到同步。
說明:上圖中,非jira相關的版本相關基本概念,摘錄自維基百科
術語 |
英文 |
說明 |
---|---|---|
基線 |
Baseline |
基線是軟件文檔或源碼(或其它產出物)的一個穩定版本,它是進一步開發的基礎。 |
修復的版本 |
Fix Version/s |
修復/發佈功能的版本,backlog 界面拖拽操作,更新的是修復版本字段 |
影響的版本 |
Affects Version/s |
故障影響的版本 |
文件庫 |
Repository |
存儲文件的新版本還有歷史資料的地方,通常是在服務器上。 |
取出 |
Check-Out |
從文件庫取出文件到本地端(客戶端)。 |
衝突 |
Conflict |
當兩方更動同一份文件會發生衝突。 |
合併 |
Merge / Integration |
合併各個改變。程序員的終極浪漫就是 調試 0 warning , 0 error ; 合併 0 conflict . |
主版本號.次版本號.修訂號,版本號遞增規則如下:
主版本號:當你做了不兼容的 API 修改,
次版本號:當你做了向下兼容的功能性新增,
修訂號:當你做了向下兼容的問題修正。
先行版本號及版本編譯元數據可以加到“主版本號.次版本號.修訂號”的後面,作為延伸。
根據用戶習慣,C端可以做產品,B端只能做定製項目,如果想做標準產品,建議出海。
項目,產品的研發團隊要區分開,如果是做一個新產品,不要想節省成本,混用產品和項目團隊。因為最終一定會搞出四不像產品。
名詞 |
範圍 |
英文 |
示例 |
---|---|---|---|
版本 |
中 |
Version |
一週~一個月發佈的軟件功能/修復包括的內容 |
史詩 |
大 |
Epic |
半年到一年,單個軟件項目,或多個項目發佈組合。 |
衝刺 |
小 |
Sprint |
1~4周,指定時間範圍內的工作範圍 |
一個 issue 可以同時存在以上三種屬性,也可以都沒有,非必選,根據跟蹤需要附上相關信息。
版本號,存在於代碼庫,issue界面,變動存在於 issue的評論區,如果真的要全部打通,技術上可行,集成以及用戶培訓都需要成本。 內置的集成 smart commit 支持 bitbucket與 GitHub
現代開發團隊,從傳統中心化,瀑布是開發,逐步向敏捷,分佈式轉換,界限在哪裡。不能走極端,比如說 傳統研發模式不需要了,全部走 git 分佈式。
中心化:大文件(如1g以上)同步,工程,遊戲,多媒體
分佈式:無單文件1g以上的工程,如軟件
操作 |
描述 |
---|---|
新增 |
在擠壓工作(backlog)或項目設置裡【管理版本】,項目開始前,擁有管理項目權限的用戶,新增版本,名稱,描述,開始,結束日期; 版本有【發佈】,【未發佈】,【已逾期】,【歸檔】四個狀態 |
發佈 |
測試,構建完成後發佈,可以在菜單左側 發行(release)按鈕 或 advanced roadmap插件裡發佈版本 |
歸檔 |
當一個版本不再被使用時,歸檔後報表和非版本管理的界面選擇無法查看到版本信息 |
删除 |
一般只會對誤添加的版本操作刪除 |
方式 |
描述 |
---|---|
界面 |
創建,編輯 issue 時更新 版本信息 |
backlog |
在backlog 界面中增刪改版本信息,並把issue拖拽到版本中 |
過濾器 |
通過過濾器批量篩選issue,更新版本字段 |
從 Jira Software 創建 Bitbucket 分支
名稱 |
作用 |
---|---|
從過去的輸出表現未來的交付穩定性以及趨勢 |
|
回顧已發佈的版本 |
|
展示團隊在具體版本中每個人的表現(已完成,剩餘任務總數等) |
Tom Zhu
Consultant
Shanghai Jingxianginfo Co., Ltd
Shanghai
7 accepted answers
0 comments