Second-Gen Packaging Migration และ Winter 21 release

Question

มีวิดีโอ YouTube ของ Salesforce Developers ตั้งแต่วันที่ 13 ธันวาคม 2019:

• ขอแนะนำแพ็คเกจรุ่นที่สองที่มีการจัดการ

ซึ่งบอกเป็นนัยว่าการเปิดตัว Winter 21 จะรวมถึง:

1. เปิดใช้งานการย้ายแพ็กเกจรุ่นแรกไปยังแพ็กเกจรุ่นที่สอง (GA)
2. ลบประเภทข้อมูลเมตาใด ๆ ออกจากแพ็คเกจที่มีการจัดการ (นำร่อง)

แต่ดูที่บันทึกประจำรุ่นสำหรับแพ็คเกจ:

• บันทึกประจำรุ่นของ Salesforce Winter '21: บรรจุภัณฑ์: การแสดงภาพบรรพบุรุษของแพ็กเกจ, เวอร์ชันแพ็กเกจที่ไม่ต้องการสามารถลบได้, โดยทั่วไปแล้วการอัปเกรดแบบพุชจะพร้อมใช้งาน

ดูเหมือนว่าพวกเขาไม่ได้เข้าสู่การเปิดตัว

1. ใครมีข้อมูลเชิงลึกเกี่ยวกับสถานะของคุณสมบัติเหล่านี้หรือไม่?
2. กระบวนการปัจจุบันในการโอนย้ายแพ็กเกจรุ่นแรกไปยังรุ่นที่สองเป็นอย่างไร
3. สายเกินไปหรือไม่ที่จะย้ายไปใช้ gen ที่สองถ้าฉันเริ่มสร้างแพ็คเกจในองค์กร dev ที่มีเนมสเปซ แต่ยังไม่ได้อัปโหลดอะไรเลย (ไม่ใช่เบต้า)

Answer 1

สำหรับรายการที่ 1 และ 2 งานอยู่ระหว่างดำเนินการและไม่สามารถเปิดเผยวันที่ต่อสาธารณะได้

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

สำหรับคำถามที่สามของคุณด้านล่าง

สายเกินไปหรือไม่ที่จะย้ายไปใช้ gen ที่สองถ้าฉันเริ่มสร้างแพ็คเกจในองค์กร dev ที่มีเนมสเปซ แต่ยังไม่ได้อัปโหลดอะไรเลย (ไม่ใช่เบต้า)

ไม่มันยังไม่สายอันที่จริงมันเป็นเวลาที่เหมาะสมอย่างยิ่งที่จะย้ายไปใช้แพ็คเกจ 2GP

ตราบเท่าที่คุณไม่มีหมวดหมู่ Metadataที่จะไม่รองรับใน 2GP คุณควรย้ายไปที่ 2GP เนื่องจากมีข้อดีหลายประการ ไม่มีประเด็นในการใช้บรรจุภัณฑ์ 1GP

กระบวนการเริ่มต้นกับ 2GP สำหรับคุณนั้นตรงไปตรงมาจริงๆ

• เปิดใช้งานDev Hubในองค์กรธุรกิจคู่ค้าของคุณ (สมมติว่าคุณมีสิ่งนี้เนื่องจากคุณเป็น ISV)

• เชื่อมโยงองค์กร Dev ของคุณที่คุณมี Namespaced กับDev Hubองค์กรของคุณ

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

• ดึงข้อมูลเมตาทั้งหมดจากแพ็คเกจไปยังพื้นที่ทำงานโครงการในพื้นที่ของคุณ (ใช้sfdx force:project:createเพื่อนั่งร้านโครงการ Salesforce DX และอนุญาต Salesforce CLI กับ DevHub และ Dev org ของคุณ) โดยใช้ด้านล่าง

  sfdx force: ที่มา: ดึง -n ""

• สร้างแพ็กเกจที่มีการจัดการ 2GP และเวอร์ชันแพ็กเกจโดยใช้คำสั่งบรรจุภัณฑ์

  sfdx force:package:create

  sfdx force:package:version:create

ประเด็นสำคัญที่ควรทราบในแพ็คเกจ 2GP ที่ใหม่เทียบกับ 1GP

• คุณไม่สามารถสร้างแพ็กเกจ 2GP โดยใช้ UI ตัวจัดการแพ็กเกจ CLI เป็นตัวขับเคลื่อนและคุณจะต้องสบายใจกับ Salesforce CLI

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

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

• แพคเกจที่มีการจัดการ 2gp มีแนวคิดของแพคเกจบรรพบุรุษ สิ่งนี้ช่วยในการแยกรหัสของคุณหากจำเป็น ดังนั้นสิ่งสำคัญคือคุณต้องแท็กบรรพบุรุษก่อนที่จะปล่อยแพ็คเกจ

• คุณสามารถใช้ Scratch orgs และใช้ความสามารถในการติดตามแหล่งที่มาเพื่อผลักดันและดึงข้อมูลเมตา

Answer 2

ใครมีข้อมูลเชิงลึกเกี่ยวกับสถานะของคุณสมบัติเหล่านี้หรือไม่?

ฉันไม่คิดว่าจะมีใครพูดอะไรต่อสาธารณะ (#SafeHarbor และทั้งหมดนั้น) แต่ฉันแน่ใจว่าพวกเขากำลังดำเนินการอยู่

กระบวนการปัจจุบันในการโอนย้ายแพ็กเกจรุ่นแรกไปยังรุ่นที่สองเป็นอย่างไร

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

สายเกินไปหรือไม่ที่จะย้ายไปใช้ gen ที่สองถ้าฉันเริ่มสร้างแพ็คเกจในองค์กร dev ที่มีเนมสเปซ แต่ยังไม่ได้อัปโหลดอะไรเลย (ไม่ใช่เบต้า)

ไม่ใช่เลย! คุณสามารถเชื่อมโยงเนมสเปซของคุณกับองค์กร Dev Hub ของคุณและจากที่นั่นคุณสามารถสร้างแพ็กเกจรุ่นที่สองหลังจากแปลงจากรูปแบบ Metadata API (MDAPI) เป็นรูปแบบ Source ซึ่งโดยทั่วไปจะทำได้ง่ายเพียงแค่บังคับ: source: ดึง -x หรือบังคับ : mdpai: แปลง. โปรดทราบว่าคุณสามารถทำได้แม้ว่าคุณจะอัปโหลดข้อมูลเมตา แต่ก็ไม่สามารถแปลงได้ ฉันไม่แนะนำให้ดูแลสองแพ็คเกจแม้ว่า; หากคุณเริ่มต้นใหม่ตอนนี้เป็นเวลาที่จะเริ่มใช้งาน Second Generation Packaging (เว้นแต่ว่ายังไม่รองรับประเภทข้อมูลเมตาอย่างน้อยหนึ่งประเภท ) สิ่งนี้ช่วยให้คุณสร้างแพ็กเกจได้ไม่ จำกัด จำนวนที่ทุกคนสามารถแชร์เนมสเปซเดียวกันได้ (แต่อย่าลืมใช้ @NamespaceAccessible หากคุณวางแผนที่จะแชร์โค้ดข้ามแพ็กเกจ)