เวิร์กโฟลว์ที่แนะนำสำหรับการโอนย้ายการกำหนดค่า (CMI) จาก dev -> stage -> การผลิตคืออะไร

41

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

สิ่งที่ดีที่สุดที่เราอยู่ในห้องนั้นสามารถคิดออกได้ (บางส่วนขึ้นอยู่กับการนำเสนอที่ DrupalCon Portland) คือ:

บอกการควบคุมเวอร์ชันเพื่อละเว้นไดเรกทอรี config ที่ใช้งานอยู่
คัดลอกการกำหนดค่าทั้งหมดไปยังไดเรกทอรีจัดเตรียมและกระทำการควบคุมเวอร์ชัน

และใช้ settings.php เพื่อย้อนกลับ active / staging directory ระหว่าง 2 environment อย่างไรก็ตามในขณะที่การหาเวิร์กโฟลว์การปรับใช้จากเซิร์ฟเวอร์หนึ่งไปยังเซิร์ฟเวอร์ถัดไปนั้นมีความซับซ้อน แต่สามารถทำได้เวิร์กโฟลว์ที่แนะนำจากสภาพแวดล้อมในท้องถิ่นหลายแห่ง (เช่นนักพัฒนาหลายคน) ไปสู่ dev (หรือระหว่างกัน) - ปัญหาที่เป็นไปได้ จะแบ่งปันสภาพแวดล้อมแบบเดียวกันหรือคล้ายกันดังนั้นการเปลี่ยนแปลงในเครื่องของเพื่อนร่วมทีมคนหนึ่งจะเกิดขึ้นได้อย่างไร?

migration 8 version-control

— btmash
แหล่งที่มา

5

ฉันไม่เห็นด้วยกับการโหวตอย่างใกล้ชิดในปัจจุบัน เนื่องจาก CMI เป็นจุดสนใจของ Drupal 8 ฉันคิดว่าเราสามารถมีคำตอบที่ดีได้ที่นี่

— mpdonadio

3

เห็นด้วยนี่เป็นคำถามที่ดีมาก ฉันเชื่อว่าภารกิจที่สำคัญdrupal.org/node/1703168เป็นเรื่องเกี่ยวกับเรื่องนี้และหัวข้ออื่น ๆ และยังไม่ได้รับการแก้ไขอย่างสมบูรณ์ดังนั้นคำตอบที่นี่สามารถช่วยผลักดันปัญหานั้นไปข้างหน้า

— Berdir

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

— btmash

2

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

— donquixote

1

แก้ไขชื่อดังนั้นคำถามสามารถมองเห็นได้ทั้งโดยแท็กหรือผ่านทางชื่อ :)

— btmash

19

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

พยายามที่จะรักษามันสั้น ๆ ตอนนี้จะพยายามขยายตามคำถาม / เมื่อปัญหาที่อ้างอิงได้รับการแก้ไขด้วยคำตอบอย่างเป็นทางการ

ดังนั้นก่อนข้อเท็จจริง ...

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

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

— Berdir
แหล่งที่มา

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

— btmash

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

— Berdir

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

— btmash

และการติดตาม: (A) จะมีกลไกในการคัดลอกการเปลี่ยนแปลงจาก active directory -> staging (เพื่อให้ง่ายขึ้นเมื่อเทียบกับบุคคลที่จะเข้าไปในไดเรกทอรี config สำหรับส่วนประกอบเหล่านี้ - อาจเป็นวิธีที่จะเลือกตัวแปรบางอย่างได้) (B) ไดเรกทอรีการแสดงละครว่างเปล่าหลังจากการเปลี่ยนแปลงถูกซิงค์จากการจัดลำดับ -> ใช้งานอยู่หรือไม่ (B1) ถ้าเป็นเช่นนั้นกลยุทธ์จากมุมมอง devops เพื่อรีเซ็ตไดเรกทอรีนั้นก่อนที่จะดึง git หรือไม่? (B2) ถ้าไม่เป็นเช่นนั้นถูกต้องหรือไม่ที่จะสมมติว่าในขณะที่ staging-> active sync เกิดขึ้นจะไม่มีผลกระทบใด ๆ ต่อการกำหนดค่าที่ไม่เปลี่ยนแปลง

— btmash

สถานะการติดตั้งโมดูลคือการกำหนดค่า ไม่ใช่โมดูลเอง :) นั่นคือสิ่งที่คุณปรับใช้ ก) มี UI สำหรับดาวน์โหลด tar.gz ของไดเรกทอรีที่ใช้งานอยู่หนึ่งรายการที่จะอัปโหลด tar.gz กล่าวไว้ในไดเรกทอรีจัดเตรียมและอีกหนึ่งการนำเข้าจริงพร้อมด้วยภาพรวมและความแตกต่างของการเปลี่ยนแปลง B) ฉันเชื่อว่าตอนนี้มันว่างเปล่า แต่ฉันคิดว่าคุณสามารถย้อนกลับได้อย่างง่ายดายด้วย git ไม่แน่ใจตรวจสอบง่าย ทุกอย่างเป็นสิ่งที่เสียบได้ดังนั้นอาจมีการนำไปใช้ที่แตกต่างกันเล็กน้อยซึ่งไม่ได้ลบ B2) ฉันไม่ได้รับอันนี้ แต่ฉันคิดว่าใช่

— Berdir

4

เยี่ยมมากเลย ขอบคุณทุกคน!

เราเริ่มโครงการ Drupal 8 เมื่อเร็ว ๆ นี้และใช้เวิร์กโฟลว์ต่อไปนี้

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

เทมเพลตโครงการ drupal 8 ปัจจุบันของเรามีให้ที่ github ฉันยังเขียนคำสั่ง drush ที่มีประโยชน์บางส่วนเพื่อเร่งความเร็ว devleoper worflow ไม่มีการคัดลอกด้วยตนเองจากใช้งานเพื่อการส่งออกที่จำเป็น

เทมเพลตโครงการ: https://github.com/webflo/d8-project-template
คำสั่ง Drush เพิ่มเติม: https://github.com/webflo/d8-project-template/blob/master/public/drush/cmi.drush.inc

— Webflo
แหล่งที่มา

1

จนถึงตอนนี้ฉันเห็นด้วยกับวิธีการนี้ ฉันได้เพิ่มคุณสมบัติทั้งหมดจากลิงค์ในโพสต์นี้ไปยังคำสั่ง config-export และคำสั่ง config-import ของ Drush ฉันหวังว่าคนอื่นจะเข้าร่วมฉันและ @florian ในการสำรวจโซลูชันไดเรกทอรี 3 นี้

— moshe weitzman

คุณจัดการกับsites/default/files/config_HASHโฟลเดอร์การตั้งค่าที่มีคำต่อท้ายแฮชได้อย่างไรเช่น config_wNOLcmycPFZCrXJ9wis9dCdSR4lpYILdBsFxSWuK5Hzhcr

— therobyouknow

@therobyouknow เป็นไปได้ที่จะแทนที่ตำแหน่งของโฟลเดอร์เหล่านี้ เพียงมองหา "ตำแหน่งของไฟล์การกำหนดค่าไซต์" ใน settings.php ฉันใช้ตัวอย่างต่อไปนี้ นี่หมายถึงการกำหนดค่าจะถูกเก็บไว้ด้านนอกของรูตของ Drupals $ config_directories = array ('active' => '../config/active', 'staging' => '../config/staging',);

— webflo

ขอบคุณ @webflo ฉันเห็นสิ่งนี้ การจัดการฐานรหัสและการกำหนดค่าแยกกันจะมีประโยชน์อย่างไร ฉันคิดว่าการแยกนี้เป็นสิ่งประดิษฐ์เล็กน้อยเนื่องจากทั้งโค้ดและ config (เป็น yaml) เป็นตัวกำหนดพฤติกรรมและขึ้นอยู่กับกันและกัน ใน Drupal 7 การกำหนดค่าในโค้ด (หรือติดตามได้โดย Git) ได้ทำกับโมดูลคุณลักษณะการสร้างโมดูลสำหรับการกำหนดค่าเฉพาะที่จำเป็นต้องมีการติดตามในรหัส ใน Drupal 8 มีฟีเจอร์ 3.x ที่ฉันเข้าใจมันทำแบบเดียวกัน แต่ใช้ YAML เพื่อเก็บการตั้งค่าและโมดูลที่สร้างขึ้นไม่ได้ขึ้นอยู่กับโมดูลฟีเจอร์

— therobyouknow

ฉันคิดว่าคุณเข้าใจฉันผิด dir config ยังคงอยู่ในคอมไพล์ แต่ไซต์ Drupal ของฉันไม่ได้อยู่ในราก git repo เว็บไซต์ถูกจัดเก็บ / เว็บ ดังนั้น / config และ / web อยู่ในระดับเดียวกัน

— webflo

2

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

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

การกำหนดค่าในโมดูลที่กำหนดเองทำให้มันเป็นส่วนหนึ่งของ codebase หลักของคุณ

กระบวนการปรับใช้จะเป็น:

Git pull หรืออะไรก็ตามที่จะได้รับไฟล์ใหม่
ล้างแคช
รีเซ็ตการกำหนดค่าเริ่มต้น (จากไฟล์โมดูลที่กำหนดเองของคุณ)

คุณสามารถสร้างโมดูลที่กำหนดเอง (ด้วยการกำหนดค่าของตัวเอง) สำหรับแต่ละสภาพแวดล้อมหากคุณต้องการ

— jonpugh
แหล่งที่มา

ฟังดูเหมือนคุณสมบัติมากมายใช่ไหม? หรือมีความแตกต่างอย่างมีนัยสำคัญฉันหายไป?

— Letharion

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

— btmash

2

หมายเหตุ: ฉันขอขอบคุณที่นี่ไม่ใช่คำตอบในแง่ที่เข้มงวดที่สุดเกี่ยวกับคำถาม แต่ฉันได้ใส่ไว้ที่นี่แล้วและฉันจะกลับมาและแก้ไข / ลบเมื่อคุณสมบัติมีรุ่น 8.x และฝุ่นมี ตัดสินอีกเล็กน้อย นี่มันใหญ่เกินไปสำหรับความคิดเห็นและฉันต้องการรับ 0.02 ปอนด์ของฉันใน :-)

ในฐานะที่เป็นแฟนใหญ่ของคุณสมบัติผมขอแนะนำการรักษาตาในคุณสมบัติของโมดูล D8 ชาติ

นำมาจากหน้าโครงการ

ฟีเจอร์เวอร์ชัน 3.x ได้รับการวางแผนสำหรับ Drupal 8 เพื่อรวมเข้ากับระบบการจัดการการกำหนดค่าใหม่ หากคุณต้องการส่งออกการกำหนดค่าไซต์แบบง่ายระบบการจัดการการกำหนดค่า D8 ควรใช้แทนฟีเจอร์ คุณจะใช้คุณสมบัติใน D8 เพื่อส่งออกฟังก์ชั่นที่รวมไว้ (เช่น "คุณสมบัติแกลเลอรี่ภาพ")

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

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

— Chapabu
แหล่งที่มา

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

— btmash

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

— btmash

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

— Berdir

คุณถูก. ฉันไม่ทราบว่าฉันจะได้รับโมดูลการกำหนดค่าสำหรับ D7 ปะปนกับฟีเจอร์ได้อย่างไร

— btmash