คู่มือ: การจัดการการเปิดตัวซอฟต์แวร์สำหรับทีมขนาดเล็ก

การทำให้กระบวนการจัดการการเผยแพร่เป็นทางการ (ถ้ามี)

ในการกำหนดค่าของทีมบางประเภท โดยเฉพาะอย่างยิ่งการกำหนดค่าที่พบในสตาร์ทอัพ ไม่มี DevOps หรือวิศวกรโครงสร้างพื้นฐานที่จะให้การสนับสนุนเมื่อเปิดตัวผลิตภัณฑ์เวอร์ชันใหม่

ยิ่งไปกว่านั้น แตกต่างจากบริษัทระบบราชการขนาดใหญ่ที่มีกระบวนการที่เป็นทางการที่กำหนดไว้ CTO หรือหัวหน้าทีมพัฒนาซอฟต์แวร์ในการเริ่มต้นมักไม่ทราบถึงความซับซ้อนของกระบวนการจัดการการเผยแพร่ซอฟต์แวร์ นักพัฒนาบางรายในบริษัทอาจทราบถึงรายละเอียดที่ซับซ้อนของกระบวนการ แต่ไม่ใช่ทุกคน หากความรู้นี้ไม่ได้ รับการบันทึกอย่างละเอียด ฉันเชื่อว่าอาจส่งผลให้เกิดความสับสน

ในบทความนี้ ฉันจะพยายามให้เคล็ดลับเกี่ยวกับวิธีการทำให้กระบวนการเผยแพร่เป็นทางการ โดยเฉพาะอย่างยิ่งจากมุมมองของนักพัฒนาซอฟต์แวร์

เข้าสู่รายการตรวจสอบการวางจำหน่ายซอฟต์แวร์

คุณอาจคุ้นเคยกับแนวคิดของรายการตรวจสอบสำหรับการดำเนินการบางอย่าง ตาม ประกาศรายการตรวจสอบ ซึ่งเป็นหนังสือของ Atul Gawande ฉันเชื่อว่ากระบวนการเผยแพร่อย่างเป็นทางการ (เช่นเดียวกับงานอื่นๆ ในโลกของการพัฒนาซอฟต์แวร์) เปิดโอกาสให้นักพัฒนาได้ใช้โปรโตคอลนี้ รายการตรวจสอบกระบวนการเผยแพร่ควรเก็บไว้ในเอกสารที่แชร์ โดยควรอยู่ในรูปแบบวิกิที่ทำงานร่วมกัน หรือสเปรดชีตใน Google ไดรฟ์

ด้วยการแบ่งปันเอกสารสำคัญนี้กับทีม และการอนุญาตให้แก้ไข สมาชิกทุกคนสามารถเข้าถึงกระบวนการเผยแพร่ที่กำหนดไว้อย่างเป็นทางการ ซึ่งช่วยให้พวกเขาเข้าใจว่ากระบวนการทำงานอย่างไร นอกจากนี้ จากการหารือกับสมาชิกในทีมคนอื่นๆ จะช่วยให้ทีมสามารถปรับปรุงได้ตลอดเวลา สิ่งนี้ควรนำมาซึ่งความโปร่งใสและช่วยให้ทั้งทีมสามารถเข้าถึงสิ่งที่เกิดขึ้นในระหว่างการเผยแพร่ได้แบบเรียลไทม์ ขั้นตอนใดบ้างที่เสร็จสิ้น และโดยใคร

เมื่อดูที่สเปรดชีตนี้ ผู้มีส่วนได้ส่วนเสียสามารถตัดสินใจได้ว่า 'ไป' กับ 'ไม่ไป' ตามผลลัพธ์ของขั้นตอน ตัวอย่างเช่น หากการทดสอบความเครียดเกิดข้อผิดพลาดในสภาพแวดล้อมการทดสอบ ตามเหตุการณ์ที่ผู้จัดการโครงการอาจตัดสินใจยกเลิกรุ่นที่ใช้งานจริง

ขั้นตอนที่แนะนำเพื่อใช้เป็นรองพื้น

ในส่วนนี้ ฉันจะเสนอขั้นตอนบางอย่างที่คุณสามารถใช้เพื่อสร้างรายการตรวจสอบสำหรับกระบวนการเผยแพร่ของคุณ บางขั้นตอนเหล่านี้ ไม่ได้บังคับ แต่ละแอปมีความแตกต่างกันและแต่ละองค์กรทำงานในลักษณะที่แตกต่างกัน ดังนั้นอย่าลังเลที่จะปรับเปลี่ยนและทำการเปลี่ยนแปลงที่เหมาะสมกับเวิร์กโฟลว์ของคุณมากขึ้น

1. สร้างสาขาที่วางจำหน่าย

เป็นไปได้ว่าคุณคุ้นเคยกับแนวคิดของ Git Workflow หรือแนวคิดของสาขาที่วางจำหน่าย ซึ่งเป็นหัวข้อที่ได้อธิบายไว้ในบล็อกโพสต์ก่อนหน้านี้

คุณควรมีอย่างน้อยสามสาขา:

• master : สิ่งนี้ควรสะท้อนถึงสถานะปัจจุบันของสิ่งที่อยู่ในสภาพแวดล้อมการผลิต ทุกคอมมิตบน มาสเตอร์ ควรประกอบด้วยรีลีสใหม่เท่านั้น
• พัฒนา : สาขานี้ควรมีคุณสมบัติที่จะเกิดขึ้น (และทดสอบแล้ว) ที่เสร็จสมบูรณ์แล้ว เป็นเรื่องปกติที่จะสร้างแบรนช์แยกต่างหากสำหรับแต่ละฟีเจอร์ แล้วรวมเข้าด้วยกันเพื่อ พัฒนา เมื่อฟีเจอร์พร้อม
• รี ลี ส : รี ลี สสาขาคือชุดของคอมมิตที่พร้อมส่งไปยังเวอร์ชันที่ใช้งานจริง บวกกับการแก้ไขข้อบกพร่องเล็กน้อยเพิ่มเติมที่เกี่ยวข้องกับรีลีส

สังเกตว่าสาขาที่ วางจำหน่าย ควรถูกลบออกเมื่อการวางจำหน่ายเสร็จสิ้น ดังนั้นสาขาเหล่านี้จึงถูกสร้างขึ้นและถูกทำลายตลอดเวลา ไม่เหมือนกับ master หรือ development ซึ่งเหมือนกันเสมอ

ในการสร้างสาขารี ลี สใหม่ จากสาขาที่ พัฒนา ในเทอร์มินัล git ของคุณ ให้พิมพ์:

$ git checkout -b release/xyz

สะดวกในการใช้หลักการตั้งชื่อ เช่น ที่กำหนดไว้ข้างต้น โดยแทนที่ xyz ด้วยหมายเลขเวอร์ชัน major.minor.patch ตามความต้องการของคุณ (เป็นนโยบายที่คุณควรกำหนดภายในทีมของคุณและปฏิบัติตาม)

สิ่งสำคัญที่ต้องพูดเช่นกันว่า หากคุณเขียนโค้ดการแก้ไขข้อผิดพลาดบางอย่างลงในรีลีสแบรนช์ คุณไม่ควรลืมที่จะรวมกลับเพื่อ พัฒนา วัตถุประสงค์หลักของรีลีสแบรนช์คือการมีสแนปชอตตัวอย่างว่าแอปควรทำงานอย่างไรหลังจากเริ่มใช้งานจริง

2. เวอร์ชั่นชน

ขั้นตอนต่อไปคือการชน (แก้ไขหรือเพิ่ม) หมายเลขเวอร์ชันในสาขาการ เผยแพร่

คุณควรเปิด AndroidManifest.xml / package.json / pom.xml / หรือทุกที่ที่มีการจัดเก็บเวอร์ชันของแอปไว้ในโปรเจ็กต์ของคุณ (YMMV) อัปเดตหมายเลขเวอร์ชัน จากนั้นคอมมิตการเปลี่ยนแปลงไปยังสาขาการ เผยแพร่ ปัจจุบัน

สิ่งสำคัญคือต้องอัปเดตหมายเลขเวอร์ชันด้วยเหตุผลสองประการ

ขั้นแรก คุณสามารถติดตามและแมปคุณลักษณะที่นำมาใช้ในแต่ละเวอร์ชัน และประการที่สอง คุณจะทราบถึงเวอร์ชันที่พวกเขาใช้อยู่หากจำเป็นต้องทำการแก้ไขปัญหาหรือติดต่อคุณเพื่อขอรับการสนับสนุน หากคุณกำลังสร้างแอปมือถือ หมายเลขเวอร์ชันที่คุณกำลังอัปเดตในขั้นตอนนี้มักจะแสดงที่ผู้ใช้ปลายทาง ในส่วน เกี่ยวกับ หรือใน Google Play หรือ Apple App Store ขั้นตอนนี้ยังเป็นโอกาสที่ดีในการอัปเดตตามสภาพแวดล้อม - ไฟล์การกำหนดค่า (แม้ว่าฉันจะแนะนำให้เก็บไว้ในที่เก็บแยกต่างหาก) เช่นการทำให้สาขาชี้ไปที่ฐานข้อมูลการผลิตหรือปรับแต่งอื่น ๆ ที่จำเป็นในกระบวนการสร้าง

สุดท้าย ขอแนะนำให้คุณพุชรี ลี สแบรนช์ไปที่ต้นทาง ดังนั้นจึงพร้อมใช้งานสำหรับนักพัฒนาคนอื่นๆ ของคุณ:

$ git push -u origin release/xyz

3ก. รวมรีลีสแบรนช์เพื่อมาสเตอร์และแท็กมัน

เฉพาะสาขา หลัก เท่านั้นที่จะถูกปรับใช้สำหรับการผลิต ดังนั้นในขั้นตอนนี้ เราจำเป็นต้องรวมสาขาที่ วางจำหน่าย เป็น master

 $ git checkout master $ git merge --no-ff release/xyz $ git push

แฟ --no-ff เป็นทางเลือก อย่างไรก็ตาม แนะนำให้ใช้แฟล็กเพื่อบังคับให้สร้างอ็อบเจ็กต์การคอมมิตใหม่ แม้ว่าการผสานจะเสร็จสมบูรณ์โดยใช้เทคนิคการกรอไปข้างหน้า

ต่อไป ได้เวลาติดแท็กการเปิดตัวบนสาขา หลัก :

$ git tag -a xyz -m 'description of new version, features or fixes included'

แท็กมีประโยชน์เนื่องจากคุณกำลังคงจุดเฉพาะนี้ไว้ในประวัติในที่เก็บ git และคุณสามารถกลับมาสร้างสาขาใหม่แยกจากแท็กเฉพาะได้ในภายหลัง

3b. ใช้คำขอดึงเพื่อรวมสาขาที่วางจำหน่าย

อีกทางเลือกหนึ่งที่ใช้บ่อยคือการใช้ pull request เพื่อรวม release branch ลงใน master

มีข้อดีหลายประการสำหรับวิธีนี้ พื้นที่ใหม่ถูกสร้างขึ้นสำหรับการทำงานร่วมกัน ซึ่งทีมสามารถใช้เพื่อหารือเกี่ยวกับปัญหาต่างๆ ที่เกี่ยวข้องกับการเปิดตัว จุดนี้เป็นเวลาที่ดีที่จะเพิ่มประตูพิเศษสำหรับการรวมกระบวนการตรวจสอบโค้ด ในขณะที่มีดวงตามากมายที่จะคอยตรวจสอบโค้ดที่จะเปิดตัว และเพื่อหารือเกี่ยวกับการปรับเปลี่ยนที่อาจเกิดขึ้น

เครื่องมือบางอย่างที่อนุญาตให้คุณใช้การดึงคำขอในเวิร์กโฟลว์ของคุณคือ GitHub, Bitbucket และ GitLab (คำขอรวมตามที่เรียกในตอนหลัง) ด้วยเครื่องมือเหล่านี้ คุณไม่ต้องพิมพ์คำสั่ง git ด้วยตนเอง แต่คุณจะใช้เว็บอินเตอร์เฟสเพื่อตั้งค่าสาขาต้นทาง ( release ) และสาขาปลายทาง ( master ) จากนั้นคุณเพิ่มผู้ตรวจสอบอย่างน้อยหนึ่งคน ทุกคนจะ สามารถเขียนความคิดเห็นแบบอินไลน์เกี่ยวกับการเปลี่ยนแปลงใหม่เหล่านี้ แนะนำการปรับปรุง และอื่นๆ

หลังจากที่ผู้ตรวจสอบทั้งหมดอนุมัติคำขอดึงแล้ว คุณสามารถรวมการเปลี่ยนแปลงลงในข้อมูล หลัก ได้โดยอัตโนมัติโดยกดปุ่มบน UI

4. ปรับใช้ Master กับสภาพแวดล้อมการผลิต

ในขั้นตอนนี้ เป็นการดีที่จะให้ผู้ทดสอบในทีมของคุณทำการ ทดสอบควัน (ซึ่งสามารถกำหนดได้ในรายการตรวจสอบแยกต่างหาก) ก่อนที่จะปรับใช้แอป ข้อเสนอแนะที่ดีคือการปรับใช้ มาสเตอร์ แบรนช์ในสภาพแวดล้อมการทดสอบที่แยกจากกัน ผู้ทดสอบสามารถดำเนินการพื้นฐานบางอย่างเพื่อให้แน่ใจว่าไม่มีอะไรผิดพลาดหลังจากการผสานในบิลด์ล่าสุด วิธีดำเนินการทดสอบควันอยู่นอกเหนือขอบเขตของบทความนี้ แต่คุณสามารถหาเนื้อหามากมายบนเว็บเกี่ยวกับเรื่องนี้ ผลลัพธ์ของการทดสอบควันสามารถรวมเข้ากับรายการตรวจสอบการเปิดตัว/สเปรดชีต เพื่อบันทึกสิ่งที่ผิดพลาด

ณ จุดนี้ คุณพร้อมที่จะปรับใช้การเปลี่ยนแปลงและทำให้ใช้งานได้จริง ไปข้างหน้าและปรับใช้สาขา หลัก ขั้นตอนนี้จะขึ้นอยู่กับกองโครงสร้างพื้นฐานที่คุณใช้ อาจเกี่ยวข้องกับการเชื่อมต่อกับอินสแตนซ์ Amazon EC2 ของคุณเพื่ออัปโหลดแอปของคุณ หรือการพุชไปยังรีโมต Heroku หรือการเชื่อมต่อผ่าน ssh ไปยัง VPS ของคุณเพื่อคัดลอกเวอร์ชันใหม่ หรือกระบวนการอื่นๆ

หลังจากอัปโหลดแอปแล้ว ตรวจสอบให้แน่ใจว่าได้ปรับใช้สำเร็จและทำงานตามที่คาดไว้

5. รวมกลับเข้าสู่ การพัฒนา และลบสาขาที่ วางจำหน่าย

ตอนนี้การเผยแพร่ใกล้จะเสร็จสมบูรณ์ คุณจะต้องการรวมสาขาการ วางจำหน่าย เข้ากับ development เพื่ออัปเดตหมายเลขเวอร์ชันหลังและโอนการแก้ไขจุดบกพร่องทั้งหมดที่ทำไปยังสาขาการพัฒนาหลัก:

 $ git checkout develop $ git merge release/xyz

ตอนนี้ได้เวลาลบ รีลี สแบรนช์:

$ git branch -d release/xyz

6. การสร้างบันทึกการเปลี่ยนแปลง

ควรมีไฟล์อยู่ที่รูทของโปรเจ็กต์ของคุณชื่อ CHANGELOG.md (หรือไฟล์ที่เทียบเท่า) ซึ่งคุณควรเพิ่มรายการใหม่ทุกครั้งที่มีรุ่นใหม่ เพื่อที่จะบันทึกทุกอย่างที่รวมอยู่ในนั้น เช่น การแก้ไขข้อผิดพลาด คุณลักษณะใหม่ ปัญหาที่ทราบและข้อมูลที่เกี่ยวข้องอื่น ๆ ในรูปแบบของบันทึกประจำรุ่น สิ่งนี้ มีประโยชน์จริง ๆ สำหรับผู้ใช้และผู้มีส่วนร่วม เพื่อดูว่ามีการเปลี่ยนแปลงใดบ้างระหว่างแต่ละรุ่น (หรือเวอร์ชัน) ของโปรเจ็กต์

รายการบันทึกการเปลี่ยนแปลงประกอบด้วยวันที่ หมายเลขเวอร์ชัน และหมายเหตุบางประการเกี่ยวกับการเปิดตัว รายการควรเก็บไว้ในลำดับย้อนกลับ นี่คือเทมเพลตง่ายๆ ที่ฉันใช้ซึ่งคุณสามารถปรับให้เข้ากับโครงการของคุณได้:

 <app's name or component released> <version xyz> | <date> <developer's name in charge of release> | <developer's email> Features: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Bugs fixed: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Enhancements: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Optional: known issues plus other release notes.

นอกจากนี้ ขั้นตอนนี้สามารถทำได้โดยอัตโนมัติโดยการเขียนโค้ดสคริปต์พื้นฐานที่ข้ามผ่านบันทึก git และสร้างรายการบันทึกการเปลี่ยนแปลงโดยอัตโนมัติ หรือใช้เครื่องมือที่ทำเช่นเดียวกัน เช่น:

• Github Changelog Generator โดย skywinder
• ReadmeGen โดย fojuth
• github-changes โดย lalitkapoor

โปรดจำไว้ว่า ระดับของระบบอัตโนมัติที่คุณได้รับนั้นแปรผันตรงกับความเข้มงวดของรูปแบบข้อความยืนยันของคุณ ฉันเชื่อว่าเป็นแนวปฏิบัติที่ดีเสมอที่จะยอมรับรูปแบบเฉพาะสำหรับส่งข้อความกับทีม โดยการปฏิบัติตามหลักเกณฑ์เกี่ยวกับรูปแบบของข้อความที่คอมมิต พวกเขาจะแยกวิเคราะห์ได้ง่ายขึ้น และด้วยเหตุนี้คุณจึงมีแนวโน้มมากขึ้นที่คุณจะสามารถสร้างการเปลี่ยนแปลงบันทึกโดยอัตโนมัติได้

7. สื่อสารกับผู้มีส่วนได้ส่วนเสีย

นี่คือที่ที่คุณมักจะทำสิ่งต่อไปนี้:

• แจ้งให้ทีมทราบผ่านเครื่องมือส่งข้อความภายใน (เช่น Slack) ว่ารุ่นใหม่เสร็จสมบูรณ์แล้ว ฉันแนะนำให้สร้างช่องใหม่ (เช่น: #releases ) เพื่อวัตถุประสงค์ในการสื่อสารเหตุการณ์ที่เกี่ยวข้องกับการเปิดตัวเท่านั้น ง่ายต่อการเพิ่ม hooks ในช่อง Slack เพื่อโพสต์ข้อความหลังจากดำเนินการแล้ว
• หรือส่งอีเมลถึงผู้มีส่วนได้ส่วนเสียพร้อมลิงก์ไปยังบันทึกการเปลี่ยนแปลง หรือแนบไฟล์บันทึกการเปลี่ยนแปลง
• เขียนบล็อกโพสต์ (ถ้าคุณมีบล็อกสำหรับแอพหรือผลิตภัณฑ์ของคุณ) หรือทวีต

สามารถดำเนินการเพิ่มเติมได้ขึ้นอยู่กับลักษณะองค์กรของคุณ สิ่งสำคัญคืออย่าลืมแจ้งว่าผลิตภัณฑ์เวอร์ชันใหม่ของคุณพร้อมให้บริการแล้ว

8. การดูแลตัวติดตามปัญหา

หลังจากดำเนินการเผยแพร่แล้ว คุณอาจต้องอัปเดตสถานะของตั๋วบางรายการเพื่อติดตามการแก้ไขจุดบกพร่องหรือคุณลักษณะต่างๆ ที่อยู่ระหว่างการผลิต โดยทั่วไปแล้ว สิ่งนี้เกี่ยวข้องกับการเปลี่ยนแท็กบางส่วน (สำหรับโครงการขนาดเล็ก ฉันใช้แท็กที่ รอการอนุมัติ ซึ่งฉันจะลบออกหลังจากการเปิดตัวเสร็จสิ้น)

หากคุณใช้เหตุการณ์สำคัญสำหรับเวอร์ชันใหม่แต่ละเวอร์ชัน คุณอาจต้องอัปเดตสถานะหรือทำเครื่องหมายว่าเสร็จสิ้น ตัวติดตามปัญหาบางตัวยังให้คุณวางแผนการปล่อยตัวและปรับให้เข้ากับการวิ่งเร็ว ติดตามว่าจุดบกพร่องกำลังปิดกั้นการเผยแพร่หรือไม่ และข้อมูลที่เป็นประโยชน์อื่นๆ

ทั้งหมดขึ้นอยู่กับว่าคุณใช้เครื่องมือนี้อย่างไร ฉันเพียงต้องการชี้ให้เห็นว่างานในการอัปเดตข้อมูลในตัวติดตามปัญหาควรรวมอยู่ในรายการตรวจสอบการเผยแพร่ของคุณ

เกี่ยวกับการทำให้กระบวนการเผยแพร่เป็นอัตโนมัติ

ผู้อ่านอาจสังเกตเห็นว่า นอกเหนือจากขั้นตอนบันทึกการเปลี่ยนแปลงที่ระบุไว้ข้างต้นแล้ว ขั้นตอนต่างๆ ที่กล่าวมาข้างต้นยังสามารถดำเนินการโดยอัตโนมัติได้เช่นกัน

ความสามารถในการทำให้บางส่วนของกระบวนการเผยแพร่เป็นอัตโนมัติถือเป็นชัยชนะครั้งใหญ่และช่วยประหยัดเวลาได้มาก ฉันแนะนำให้สร้างสคริปต์หรือหาวิธีทำให้แต่ละขั้นตอนเป็นอัตโนมัติ จากนั้นจึงทำงานเพื่อบรรลุเป้าหมายการจัดส่งที่ต่อเนื่อง การส่งมอบอย่างต่อเนื่องสามารถลดความเสี่ยง ลดต้นทุน และลดเวลาที่นักพัฒนาต้องใช้ในการจัดการรุ่น ดังนั้น คุณจะสามารถเผยแพร่ได้บ่อยขึ้นและมีประสิทธิผลมากขึ้นในแง่ของชั่วโมงที่จัดสรรเพื่อการพัฒนา

จอกศักดิ์สิทธิ์ของบริษัท DevOps คือการสามารถเปิดเวอร์ชันใหม่ได้โดยการกดปุ่ม (หรือเรียกใช้คำสั่ง) ที่จะทริกเกอร์กระบวนการเผยแพร่โดยอัตโนมัติหรือดีกว่านั้น ระบบที่จะเผยแพร่ซอฟต์แวร์เวอร์ชันใหม่ของคุณที่ เวลาที่กำหนด แน่นอนว่าสิ่งนี้ทำได้ยากมากเพราะคุณต้องทำให้กระบวนการทดสอบจำนวนมากเป็นอัตโนมัติด้วย แต่ก็ใช่ว่าจะเป็นไปไม่ได้

น้อมรับแนวปฏิบัติที่ดีที่สุด

ในส่วนนี้ ฉันจะอธิบายแนวทางปฏิบัติที่แนะนำสองสามข้อที่ฉันพบว่าสะดวก ไม่ว่าจะเป็นการทำให้กระบวนการปล่อยราบรื่นขึ้น หรือเพื่อใช้มาตรการด้านความปลอดภัยในกรณีที่มีสิ่งผิดปกติเกิดขึ้น

หาวันที่เหมาะสมที่สุดในการดำเนินการเผยแพร่

ฉันมักจะเผยแพร่แอปที่ฉันทำงานในวันพฤหัสบดี ระหว่างเที่ยงวันและปิดทำการ

หากคุณทำงานวันจันทร์ถึงวันศุกร์ ไม่ควรเริ่มงานในวันศุกร์ หากเกิดปัญหาหลังจากเผยแพร่ คุณจะไม่มีเวลาแก้ไขจนถึงวันจันทร์ (ยกเว้นกรณีที่คุณต้องการทำงานในช่วงสุดสัปดาห์) นั่นเป็นเหตุผลว่าทำไมการเผยแพร่ในวันพฤหัสบดีจึงสะดวกกว่า เนื่องจากคุณมีเวลาวันศุกร์ในการตรวจสอบเวอร์ชันใหม่หลังจากใช้งาน แก้ไขปัญหาใดๆ หรือย้อนกลับ

สิ่งสำคัญอีกประการหนึ่งที่ต้องกล่าวถึงหากคุณกำลังจัดการเว็บแอป คือการทราบเขตเวลาที่ผู้ใช้ส่วนใหญ่ของคุณตั้งอยู่ คุณควรกำหนดเวลาเผยแพร่ในช่วงที่มีการเข้าชมน้อย เพื่อลดความเสียหายที่อาจเกิดขึ้นหากมีบางอย่างล้มเหลว บางครั้ง อาจเป็นเรื่องยากเมื่อฐานผู้ใช้ของคุณกระจายไปทั่วโลก แต่อย่างไรก็ตาม คุณควรหาข้อมูลและตัดสินใจเกี่ยวกับเวลาที่ดีที่สุด

สำรองฐานข้อมูลของคุณก่อนที่จะออกใหม่

หากคุณไม่มีการสำรองข้อมูลตามกำหนดเวลาของฐานข้อมูลของคุณตามกำหนดเวลา เราขอแนะนำให้คุณเพิ่มขั้นตอนในกระบวนการเผยแพร่ของคุณเพื่อดำเนินการสำรองข้อมูลก่อนที่จะเริ่มเผยแพร่

การเปิดตัวแบบทีละขั้น

เคยสงสัยหรือไม่ว่าทำไมเมื่อผู้เผยแพร่โฆษณาประกาศว่าพวกเขาได้เปิดตัวคุณลักษณะใหม่ มันต้องใช้เวลาหลายวันหรือหลายสัปดาห์กว่าที่คุณลักษณะนั้นจะพร้อมใช้งานบนโทรศัพท์ของคุณ นั่นเป็นเพราะหลายบริษัทใช้การเปิดตัวแบบทีละขั้น

Facebook ทำแบบนี้มานานแล้ว โดยจะทดสอบคุณลักษณะใหม่กับผู้ใช้ 5 หรือ 10 เปอร์เซ็นต์ ค่อยๆ เพิ่มขึ้นจนกว่าจะถึง 100 เปอร์เซ็นต์ของฐานผู้ใช้ ในระหว่างขั้นตอนการเปิดตัวแบบทีละขั้น คุณจะต้องพิจารณาความคิดเห็นของผู้ใช้และรายงานข้อขัดข้องอย่างละเอียด ด้วยข้อมูลนี้ คุณสามารถเลื่อนการเปิดตัวหรือแก้ไขข้อผิดพลาดก่อนที่จะส่งผลกระทบต่อผู้ใช้ทุกราย

มีเครื่องมือดีๆ ใน Developer Console ของ Android ที่ใช้การเปิดตัวแบบทีละขั้นสำหรับแอป Android ของคุณ

บูรณาการอย่างต่อเนื่อง

การบูรณาการอย่างต่อเนื่องเป็นแนวทางปฏิบัติที่ควรค่าแก่การยอมรับด้วยเหตุผลหลายประการ ประการแรก ช่วยให้คุณตรวจจับข้อผิดพลาดได้ตั้งแต่เนิ่นๆ โดยจะเพิ่มอัตราการเผยแพร่ที่ประสบความสำเร็จ ประการที่สอง เป็นขั้นตอนเชิงตรรกะขั้นแรกก่อนที่จะนำส่งแบบต่อเนื่องและระบบอัตโนมัติเต็มรูปแบบตามที่อธิบายไว้ก่อนหน้านี้

Martin Fowler เป็นผู้สนับสนุนรายใหญ่ของการบูรณาการอย่างต่อเนื่อง เขาอธิบายประโยชน์มากมายที่สามารถเพิ่มลงในกระบวนการเผยแพร่ของคุณได้เมื่อใช้แนวทางปฏิบัตินี้ นี่เป็นหัวข้อที่ใหญ่และมีหนังสือและบล็อกโพสต์มากมายเกี่ยวกับเรื่องนี้ และฉันกำลังพูดถึงที่นี่เพราะฉันเชื่อว่ามันจะทำให้คุณมีความมั่นใจมากขึ้นในการดำเนินงานของคุณ ท่ามกลางข้อดีมากมายของการใช้ CI คุณจะพบว่า: ลดความเสี่ยง เพิ่มการมองเห็นเพื่อให้ทราบว่าสิ่งใดใช้ได้ผลและไม่ได้ผล การตรวจหาจุดบกพร่องก่อนหน้านี้ ความถี่ในการปรับใช้ที่เพิ่มขึ้น และอื่นๆ อีกมากมาย

จุดเริ่มต้นในการปรับใช้ CI คือการตั้งค่า “เซิร์ฟเวอร์การรวมอย่างต่อเนื่อง” เครื่องมือดีๆ ที่ควรลองคือ: CruiseControl, Bamboo, Jenkins และ Travis

Exitlude: ทุกอย่างจะออกมาดี

ก้าวร้าว เราทุกคนปกป้องบทบาทที่เราเล่น เสียใจเวลามาส่งคุณในทางของคุณ เราได้เห็นมันทั้งหมด กองไฟของความไว้วางใจ น้ำท่วมฉับพลันของความเจ็บปวด ไม่เป็นไร ไม่ต้องกังวล มันจะ ออกกำลังทั้งหมด

Exitlude นักฆ่า

กล่าวโดยสรุป สิ่งสำคัญคือต้องมีกระบวนการเผยแพร่ที่ชัดเจนสำหรับแอปของคุณ โดยไม่คำนึงถึงความซับซ้อน ฐานผู้ใช้ หรือองค์กรของคุณมีขนาดเล็ก

หากไม่ ฉันแนะนำให้คุณเริ่มคิดเกี่ยวกับขั้นตอนพื้นฐาน ใช้คู่มือนี้และคำแนะนำอื่นๆ ที่คล้ายกัน และระดมสมองกับทีมของคุณเพื่อสร้างร่างแรก ลองใช้ในรุ่นถัดไป จากนั้นทำซ้ำ ในที่สุด คุณจะต้องสร้างกระบวนการเผยแพร่ของคุณเอง

หลังจากนั้น ให้เริ่มคิดเกี่ยวกับวิธีการ ทำให้ชิ้นส่วนของกระบวนการเป็นแบบอัตโนมัติ คิดเกี่ยวกับด้านที่สามารถปรับปรุงได้ สำรวจวิธีการลดเวลาในการเผยแพร่โดยผสมผสานการเพิ่มประสิทธิภาพเล็กๆ น้อยๆ ระบบอัตโนมัติควรเป็นเป้าหมายสูงสุดของคุณ อย่างไรก็ตาม อย่าวางแผนไว้ตั้งแต่ต้น มิฉะนั้น คุณจะล้มเหลวโดยการพยายามก้าวกระโดดครั้งใหญ่ เช่นเดียวกับทุกๆ ขั้นตอน ค่อยๆ ปรับปรุงให้ดีขึ้น

คุณมีกลเม็ดหรือแนวทางอื่นๆ ที่คุณใช้ในการเปิดแอปเวอร์ชันใหม่หรือไม่ ถ้าเป็นเช่นนั้นแจ้งให้เราทราบ ฉันไม่ได้มาจากโลก DevOps ฉันเป็นเพียงนักพัฒนาที่ค่อนข้างมีระเบียบและมีโครงสร้าง แต่เมื่อเปรียบเทียบกับทหารผ่านศึกแล้ว ฉันยังเป็นสามเณรในด้านนี้ ดังนั้นอย่าลังเลที่จะแสดงความคิดเห็นหรือติดต่อฉันหากคุณมี สิ่งที่จะเพิ่ม