Salesforce Release Train: แนวทางปฏิบัติในการเผยแพร่การจัดการ

การจัดการรุ่น ตามชื่อที่แนะนำ คือกระบวนการของการจัดการ การวางแผน การจัดกำหนดการ และการควบคุมการสร้างซอฟต์แวร์ผ่านขั้นตอนและสภาพแวดล้อมที่แตกต่างกัน รวมถึงการทดสอบและปรับใช้ซอฟต์แวร์รุ่นต่างๆ (Humble & Farley, 2011)

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

แต่รถไฟปลดปล่อยคืออะไร?

การฝึกเผยแพร่เป็นเทคนิคการนำเสนอคุณลักษณะที่เพิ่มขึ้นและคาดการณ์ได้ นักพัฒนาซอฟต์แวร์ต้องตั้งค่ากระบวนการที่เป็นทางการเพื่อทำการเปลี่ยนแปลงใดๆ ที่เกิดขึ้นในสภาพแวดล้อมการพัฒนาและปรับใช้กับการผลิต

รถไฟปล่อยสามารถแบ่งออกเป็นสามส่วน:

• การจัดการข้อมูลเมตา
• การสร้างการบูรณาการอย่างต่อเนื่อง
• การจัดการแซนด์บ็อกซ์

การจัดการข้อมูลเมตา

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

Metadata API เป็นวิธีที่ดีที่สุดในการจัดการการปรับแต่งใน Salesforce รองรับการ create read update และ delete วิธีการ คุณสามารถใช้ Change Sets, Force.com IDE และ Ant Migration Tool เพื่อย้ายข้อมูลเมตาจากองค์กรหนึ่งไปยังอีกองค์กรหนึ่งได้ เนื่องจากองค์กรทั้งหมดจัดเตรียมการย้ายข้อมูลผ่าน API

เครื่องมือแต่ละอย่างมีข้อดีของตัวเอง และมีหลายสิ่งที่ควรพิจารณาเมื่อเลือกอย่างใดอย่างหนึ่ง:

ตารางที่ 1: การเปรียบเทียบเครื่องมือสำหรับการย้ายข้อมูลเมตา

Metadata API นั้นยอดเยี่ยมในการให้บริการตามวัตถุประสงค์เมื่อพัฒนาและย้ายการเปลี่ยนแปลงบนแพลตฟอร์ม Force.com แต่มีสิ่งที่จับได้เล็กน้อย - เมตาดาต้าของ Salesforce บางตัวไม่ได้รับการสนับสนุนโดย Metadata API เอกสารอย่างเป็นทางการแสดงรายการส่วนประกอบที่ไม่รองรับ

หากองค์กรของคุณกำลังทำการเปลี่ยนแปลงที่ Metadata API ไม่รองรับ คุณต้องแน่ใจว่าได้ทำซ้ำการเปลี่ยนแปลงเหล่านั้นด้วยตนเองในองค์กรปลายทาง วิธีที่ดีที่สุดในการติดตามการเปลี่ยนแปลงเหล่านี้คือสเปรดชีต หากคุณต้องใช้วิธีนี้ ขอแนะนำให้บุคคลคนเดียวทำการเปลี่ยนแปลงและติดตามการเปลี่ยนแปลงเหล่านี้เสมอ

นี่จะเป็นรายการคอลัมน์ทั่วไปที่ดีที่สามารถใช้เพื่อติดตามการเปลี่ยนแปลงเหล่านี้ในสเปรดชีต:

• ชื่อของส่วนประกอบ
• ประเภทของส่วนประกอบ
• เปลี่ยนเจ้าของ
• คำอธิบายของฟังก์ชั่น
• การทำแผนที่ความสามารถ
• การพึ่งพาส่วนประกอบอื่นๆ
• ชื่อผู้ตรวจสอบ/ผู้ตรวจสอบ
• URL
• ชื่อองค์กร/ID
• ความคิดเห็นอื่น ๆ

การควบคุมเวอร์ชันและการรวมอย่างต่อเนื่อง

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

การควบคุมเวอร์ชันเป็นสิ่งจำเป็นอย่างยิ่งสำหรับองค์กรใดๆ ช่วยให้นักพัฒนาสามารถทำงานร่วมกันได้อย่างมีประสิทธิภาพและปลอดภัย การจัดการการพัฒนาและการย้ายโค้ดแบบหลายแซนด์บ็อกซ์สำหรับนักพัฒนาหลายคนถือเป็นความท้าทายใน Salesforce Salesforce ยังมีกำหนดการสำหรับการเปิดตัวและการบำรุงรักษาของตัวเองอีกด้วย การอัปเดตเหล่านี้นำเสนอคุณลักษณะใหม่ แต่อาจแนะนำการเปลี่ยนแปลงใน Metadata API ซึ่งอาจทำลายโครงสร้าง CI ของคุณ ดังนั้น นอกเหนือจากสถานการณ์ที่นักพัฒนาเขียนทับการเปลี่ยนแปลงของกันและกัน การควบคุมเวอร์ชันจะช่วยคุณในการสร้างกลยุทธ์ย้อนกลับ ต้องมีกลยุทธ์ย้อนกลับเมื่อแอปพลิเคชันของคุณทำงานบน Force.com

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

1. นักพัฒนาจะตรวจสอบการเปลี่ยนแปลงในระบบควบคุมเวอร์ชัน
2. CI Server/Jenkins จะปรับใช้บิลด์ล่าสุดกับแซนด์บ็อกซ์ CI และรันคลาสการทดสอบ
3. หากการปรับใช้ในขั้นตอนที่ 2 สำเร็จ การเปลี่ยนแปลงจะรวมเข้ากับสาขา QA
4. CI จะปรับใช้การคอมมิตล่าสุดจากสาขา QA ไปยังแซนด์บ็อกซ์ QA
5. หาก QA ปฏิเสธการเปลี่ยนแปลงเนื่องจากความล้มเหลวในการทดสอบ ควรทำขั้นตอนที่ 1 ถึง 3 อีกครั้งจนกว่า QA จะล้างการเปลี่ยนแปลง
6. หลังจากการเปลี่ยนแปลงผ่านการทดสอบใน QA การเปลี่ยนแปลงจะถูกรวมเข้ากับสาขาหลัก
7. การเปลี่ยนแปลงล่าสุดจากสาขา Master ถูกนำไปใช้กับ Master Sandbox

สามารถเลือกเพิ่มสาขาได้ตามความต้องการขององค์กร แต่โครงสร้างข้างต้นก็ใช้ได้ดีสำหรับโครงสร้างการพัฒนาระดับกลางถึงระดับองค์กร

การจัดการแซนด์บ็อกซ์

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

แซนด์บ็อกซ์เป็นสำเนาของข้อมูลเมตาที่ใช้งานจริงเกือบทั้งหมด โดยทั่วไปแล้วแซนด์บ็อกซ์จะใช้เพื่อการพัฒนา การทดสอบ การจัดเตรียม และการฝึกอบรม Sandbox มีสี่ประเภท และประเภทหนึ่งควรคำนึงถึงในขณะที่เลือก Sandbox แซนด์บ็อกซ์ Full Copy อาจใช้เงินเป็นจำนวนมาก!

ด้านล่างนี้คือตารางสำหรับขีดจำกัดที่ Salesforce บังคับใช้สำหรับแซนด์บ็อกซ์ต่างๆ

ตารางที่ 2: การเปรียบเทียบขีดจำกัด

เราจะเห็นได้ว่าราคาไม่ใช่ความแตกต่างเพียงอย่างเดียวระหว่างแซนด์บ็อกซ์

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

ตารางด้านล่างใช้หลักการทั่วไปในการเลือกแซนด์บ็อกซ์:

ตารางที่ 3: กรณีการใช้งานสำหรับการเลือกแซนด์บ็อกซ์

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

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

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

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

กระบวนการนี้ช่วยให้เราแน่ใจว่าการเปลี่ยนแปลงต้องผ่านการทดสอบหลายรอบและผ่านสายตาหลายคู่ มาพร้อมกับข้อเสียอย่างมากที่ต้องใช้เวลานานในการพัฒนา ทดสอบ และปรับใช้การเปลี่ยนแปลง

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

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

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

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

สิ่งที่ต้องพิจารณาเมื่อคุณปรับใช้

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

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

เราจะฝากคะแนนพิเศษบางอย่างไว้ให้คุณทราบในระหว่างการปรับใช้ครั้งต่อไปของคุณ:

1. ปรับใช้ได้เพียง 10,000 ไฟล์หรือไฟล์ ZIP ขนาด 39 MB ในครั้งเดียว โดยปกติ ถ้าเพย์โหลดใหญ่เกินไป คุณต้องแบ่งแพ็กเกจออกเป็นหลายๆ ส่วน แล้วจึงทำการปรับใช้
2. หากการปรับใช้ล้มเหลวเนื่องจากข้อผิดพลาดการ request timeout ให้ลองลบอ็อบเจ็กต์ ฟิลด์ที่กำหนดเอง และโปรไฟล์ออกจากแพ็คเกจ ส่วนประกอบเหล่านี้ใช้เวลาในการปรับใช้นานขึ้น
3. หากมีการเปลี่ยนแปลงประเภทฟิลด์ หรือมีการเปลี่ยนแปลงในลำดับชั้นของบทบาท อาจมีความล่าช้าเป็นเวลานานเนื่องจากการคำนวณข้อมูลใหม่ ซึ่งต้องใช้เวลาในการดำเนินการให้เสร็จสิ้น
4. Salesforce ล็อกส่วนประกอบใดๆ ที่ผู้ใช้อยู่ในระบบใช้อยู่ในปัจจุบัน หากเราพยายามปรับใช้ในขณะที่เป็นกรณีนั้น การปรับใช้จะล้มเหลว

หวังว่าภาพรวมนี้จะช่วยคุณในการเปิดตัว Salesforce ครั้งต่อไปของคุณ

แหล่งที่มา