app branching strategy
1.0.0
เข้าใจว่าทำไม S?
master -> รหัสทดสอบล่าสุดและยิ่งใหญ่ที่สุดไม่มีลำต้นถาวรอื่น ๆ
feature/<feature_name>fix/<bug_title>release/v-<version.major>.<version.minor>auto-backmerge/<pr_number> ใช้เพื่อเพิ่ม PRS เพื่อเป็นหลักสำหรับการเปลี่ยนแปลงทุกครั้งที่ผลักดันให้ปล่อยสาขา YYMM.DD.NN
NN ➡หมายเลขแพทช์
ตัวอย่าง: 2301.25.00 , 2302.01.04
master- on-merge-master.yml ในทุกการผสานเพื่อมาสเตอร์เราจะอัปเดตเวอร์ชันเต็ม รุ่นใหญ่รุ่นรองจะได้รับการแก้ไขหากเวอร์ชันที่มีอยู่เป็นวันที่ก่อนหน้านี้มิฉะนั้นจะเพิ่มหมายเลขแพตช์เท่านั้น
ตัวอย่าง :
เวอร์ชันที่มีอยู่: 2301.25.02
หากการกระทำใหม่ถูกผลักดันเมื่อวันที่ 25 มกราคม 2566 เวอร์ชันจะกลายเป็น 2301.25.03
หากการกระทำใหม่ถูกผลักดันเมื่อวันที่ 26 มกราคม 2023 เวอร์ชันจะกลายเป็น 2301.26.00
release/**- on-merge-lelease.yml
release* ในทุกการกระทำเราจะอัปเดตหมายเลขแพตช์เมื่อ release* สาขา
release/** เข้าสู่ master - on-merge-lelease.yml ทุกการกดเพื่อ release* จะกระตุ้นการประชาสัมพันธ์ที่สอดคล้อง master ผ่านสาขา auto-backmerge/<pr_number> สาขา
PR จะถูกรวมเข้าด้วยกันโดยอัตโนมัติหากไม่มีความขัดแย้ง
- PREAPTAL-A-RELEASE.YML สร้างสาขาการเปิดตัวจาก Master ล่าสุดพร้อมเวอร์ชันที่ถูกต้องในชื่อสาขา
การกระทำ
- Create-tagged-lelease.yml แท็กการกระทำล่าสุดในสาขารุ่นที่มีแท็กเวอร์ชันที่ถูกต้องและบันทึกย่อการเปิดตัว
การกระทำ
%% {init: {'gitgraph': {'MainBranchName': 'Master', 'ShowCommitLabel': true}}} %%
กิตก ธ
ID กระทำ: "? 2301.25.00"
Branch Fix/Frames-Bug
ID กระทำ: "แก้ไขลอจิก"
ID กระทำ: "Fix UI"
Checkout Master
คุณสมบัติสาขา/DM
ID กระทำ: "เพิ่ม DB"
ID กระทำ: "เพิ่มซ็อกเก็ต"
Checkout Master
MERGE FIX/FRAMES-BUG ID: "PR: FRAMES BUG"
ID กระทำ: "? 2301.25.01"
คุณลักษณะการชำระเงิน/dm
Merge Master ID: "Pull Master"
ID กระทำ: "เพิ่ม ui"
Checkout Master
Merge Feature/DM ID: "PR: Feature DM"
ID กระทำ: "? 2301.25.02"
master ล่าสุด (การกระทำmaster และไปที่ขั้นตอนที่ 2 %% {init: {'gitgraph': {'MainBranchName': 'Master', 'ShowCommitLabel': true}}} %%
กิตก ธ
ID กระทำ: "? 2301.25.02"
การเปิดตัวสาขา/V-2301.25
Checkout Master
ID COMMEN
ID กระทำ: "? 2301.26.00"
Checkout Release/V-2301.25
Branch Fix/Release-Bug
ID กระทำ: "แก้ไขข้อผิดพลาด"
Checkout Release/V-2301.25
Merge Fix/release-bug ID: "PR: release bug"
Checkout Release/V-2301.25
สาขา Auto-backmerge/release-bug
Merge Master ID: "อัปเดตสาขา"
Checkout Release/V-2301.25
ID COMMENT: "? 2301.25.03" แท็ก: "V-2301.25.03"
Checkout Master
ผสาน Auto-backmerge/release-bug: "backmerge"
Checkout Master
ID กระทำ: "? 2301.26.01"
การกระทำ
เมื่อเราอยู่? ในการทดสอบทั้งหมดทำข้างต้นเพื่อติดแท็กคอมมิชชันล่าสุดจากสาขารีลีสและสร้างรีลีส GitHub ด้วยบันทึกย่อการเปิดตัวอัตโนมัติ และอัปโหลดสิ่งประดิษฐ์ไปยังร้านค้าแอพ
แก้ไขปัญหาในการสร้างการผลิตปัจจุบัน ( v-2301.16.01 )
v-2301.16.01 > สาขา: release/v-2301.16 )ส่วนที่เหลือเหมือนกับการไหลของการปลดปล่อยปกติ
%% {init: {'gitgraph': {'mainbranchname': 'release/v-2301.16', 'showcommitlabel': true}}} %%
กิตก ธ
ID COMMENT: "2301.16.04" แท็ก: "V-2301.16.04"
Branch Hotfix/Crash
ID กระทำ: "Fix Crash"
Checkout Release/V-2301.16
ผสาน HotFix/Crash ID: "PR Crash"
ID กระทำ: "? 2301.16.05"
Branch Hotfix/Bug
ID กระทำ: "แก้ไขข้อผิดพลาด"
Checkout Release/V-2301.16
ผสาน HOTFIX/BUG ID: "PR BUG"
ID COMMENT: "? 2301.16.06" แท็ก: "V-2301.16.06"
ประวัติศาสตร์เชิงเส้นเป็นที่ต้องการด้วยเหตุผลหลายประการ ทั้งหมดเดือดเพื่อความเรียบง่ายอีกครั้ง
การอนุญาตให้สควอชรวมกับลำตัวเดียวเป็นวิธีที่ง่ายที่สุดในการบรรลุประวัติศาสตร์เชิงเส้น ไม่มีใครคิดสิ่งที่ถูกต้องเกิดขึ้นโดยอัตโนมัติ
โดยทั่วไปแล้วผู้คนมีวินัยที่ดีกว่าเกี่ยวกับชื่อเรื่องประชาสัมพันธ์มากกว่าการส่งข้อความดังนั้นการเปลี่ยนแปลงของคุณจึงดูดี
ซึ่งแตกต่างจากแอพเซิร์ฟเวอร์กระบวนการปล่อยแอพมือถือมักจะยาว เป็นเรื่องปกติที่จะใช้เวลา 2 สัปดาห์ขึ้นไป หากเรารวมการเปิดตัวค่อยเป็นค่อยไปถึง 10%> 20%> 50%> 100% ในขณะที่สังเกตความมั่นคงและตัวชี้วัดไปพร้อมกัน
ในขณะเดียวกันผู้มีส่วนร่วม ไม่ ควรมีความคลุมเครือว่าปลอดภัยหรือไม่ที่จะรวมเข้ากับผู้เชี่ยวชาญในขณะนี้
เมื่อมีการเปิดตัวและมีการติดแท็กพวกเขาไม่มีจุดประสงค์ใด ๆ นั่นเป็นเหตุผลที่เราลบพวกเขาหลังจากเปิดตัว
กานท์
การพัฒนาแอพชื่อเรื่องและการเผยแพร่
DateFormat yyyy-mm-dd
tickinterval 3day
ส่วน Dev 1
คุณสมบัติ 2: A, 2022-01-13, 15d
ผสานกับ Master: Crit, Milestone, After a, 0d
ส่วน Dev 2
คุณสมบัติ 1: B, 2022-01-12, 2D
ผสานกับมาสเตอร์: เหตุการณ์สำคัญหลังจาก b, 0d
การอัพเกรดห้องสมุด⬆: L, 2022-01-16, 1D
ผสานกับ Master: Crit, Milestone, After L, 0d
Fix Feature 1?: B2, หลังจาก R1, 2D
ผสานเพื่อปล่อย: เหตุการณ์สำคัญหลังจาก B2, 0d
การอัพเกรดเฟรมเวิร์ก⬆: F, 2022-01-22, 1D
ผสานกับ Master: Crit, Milestone, After f, 0d
การเปิดตัวส่วน
เตรียมการเปิดตัว 2201.14: เหตุการณ์สำคัญหลังจาก B, 0d
คุณสมบัติการทดสอบ 1: R1, After B, 4D
คุณลักษณะการทดสอบ 1: R2 หลังจาก B2, 1D
การเปิดตัว 2201.14.1 10% - 100%: R3, หลัง R2, 7D
เตรียมการเปิดตัว 2201.31: เหตุการณ์สำคัญ, 2022-01-31, 0d
ผสานกับอาจารย์? ปลอดภัยและได้รับการสนับสนุนแม้ว่าการเปิดตัวจะดำเนินต่อไป
เป็นรูปแบบการกำหนดเวอร์ชันตามวันที่ที่เป็นเช่นกัน
semver ซึ่งเวอร์ชันใดมากกว่ารุ่นอื่น2301.16.00 > 2212.31.07 )และที่ดีที่สุดคือหลีกเลี่ยงคำถาม - เราปล่อยเวอร์ชันนี้เมื่อไหร่? ตลอดไปจากทุกคนในทีมทั้งหมด
แม้ว่าการตอบคำถามข้างต้นนั้นไม่สำคัญสำหรับทีมของคุณ แต่ก็ดีพอ ๆ กันถ้าไม่ดีไปกว่า semver ซึ่งทีมส่วนใหญ่ใช้โดยค่าเริ่มต้น การกำหนดเวอร์ชันความหมาย ( semver ) เหมาะสมสำหรับห้องสมุด ผู้บริโภคในห้องสมุดของคุณต้องการทราบเมื่อมีการเปลี่ยนแปลงและเมื่อไม่มี และผู้จัดการแพ็คเกจใช้ประโยชน์จากการประชุมนี้เพื่ออัพเกรดการพึ่งพาอย่างปลอดภัย ผู้ใช้แอพมือถือ / ร้านค้าแอพไม่มีความคาดหวังจากเวอร์ชันแอพ พวกเขาแทบจะไม่สนใจ
ทีมของฉันใช้รูปแบบการกำหนดรุ่นตามวันที่มานานกว่าหนึ่งปีและยอดเยี่ยมมาก!
