คำถามติดแท็ก deployment

ฉันได้ติดตั้ง JenkinsCI บนเซิร์ฟเวอร์ dev ของเราแล้วเพื่อเริ่มกระบวนการสร้างและทดสอบอัตโนมัติ ฉันใช้ Jenkins กับปลั๊กอิน Git และคำสั่ง Drush ผ่านเชลล์สคริปต์ เมื่อค้นคว้าวิธีการใช้เจนกินส์ในเวิร์กโฟลว์ dev ของฉัน Drupal ผมมาในการโพสต์เกี่ยวกับการใช้พิงค์กับ Drush และเจนกินส์ ดังนั้นฉันจึงดูที่ Phing และฉันไม่สามารถเห็นสิ่งที่ทำไม่สามารถทำได้โดยใช้คำสั่ง Drush ผ่านเชลล์สคริปต์ ฉันพยายามตัดสินใจว่าเหมาะสมหรือไม่ที่จะใช้เวลาในการเรียนรู้วิธีใช้ Phing ฉันกำลังมองหาความชัดเจนว่าฉันจะได้ประโยชน์อะไรจากการรวมคำสั่ง Phing กับ Drush ผ่านเชลล์สคริปต์ ดังนั้นคำถามของฉันสำหรับผู้ที่ใช้ Phing กับ Drush และ Jenkins: Drush / Drush-Make และ Phing แตกต่างกันอย่างไร ทำไมคุณถึงตัดสินใจที่จะเริ่มใช้ Phing ในกระบวนการของคุณ? ขอบคุณ

24 drush  deployment  jenkins 

เรามีโมดูลที่กำหนดเองซึ่งใช้สำหรับเว็บไซต์หลายแห่ง โมดูลเหล่านั้นไม่สามารถเผยแพร่เป็นโมดูลที่สนับสนุนได้เช่นเนื่องจากเป็นไคลเอนต์เฉพาะทำให้สมมติฐานที่ใช้ไม่ได้กับโมดูลที่สนับสนุนและอื่น ๆ ฉันรู้เกี่ยวกับความเป็นไปได้ที่จะจัดการกับสิ่งนี้: คัดลอกและวางไว้รอบ ๆ ทำให้เป็นการยากที่จะทำให้โมดูลทันสมัยในการติดตั้งทั้งหมด มีการติดตั้งแบบหลายไซต์ครั้งเดียว แต่ไม่สามารถทำได้ ใช้ submodules git แต่พวกเขาก็น่ารังเกียจมันง่ายที่จะลืมพวกเขาและไม่สนับสนุนเสมอ (เช่น Pantheon) Drush สร้างสคริปต์เพื่อตรวจสอบจากที่เก็บคอมไพล์ทั่วไป สำหรับสิ่งนี้คุณ AFAIK จำเป็นต้องใช้ drush make สำหรับทั้งไซต์และเราไม่ได้ใช้งานเลย http://drupal.org/project/fserver ฉันยังไม่ได้ลองมันเลยมีใครรู้บ้างไหมว่ามันเสถียรเพียงพอหรือไม่ คำอธิบายโครงการไม่ได้มีแนวโน้มมากและไม่มีรุ่นที่ 7.x มีอะไรอีกหรือดีกว่า คุณชอบอะไรและทำไม

19 version-control  deployment  drush 

บางโมดูลมีการยกเลิกการติดตั้ง ซึ่งโดยทั่วไปแล้วจะลบฐานข้อมูลสำหรับโมดูลนั้นตัวแปรจากตารางตัวแปรและตำแหน่งที่แนะนำโดยโมดูลนั้น รูทีนเหล่านี้อาศัยอยู่ใน.installโมดูลนั้น ดังนั้นจึงไม่สามารถรันได้หากไม่มีโมดูลนั้นอยู่ ดังนั้นนี่คือขั้นตอนปัจจุบันของเรา คำถามของฉันคือ: สิ่งนี้สามารถทำได้ง่ายขึ้นและมีประสิทธิภาพมากขึ้น? บอกว่าฉันลบโมดูล foo_bar ใน RCS ให้เตรียมรีลีสใหม่โดยที่: css และการแทนที่ธีมทั้งหมดที่ใช้หรือสร้างที่ด้านบนของ foo_bar จะถูกลบออก css และ theme-overrides สำหรับโมดูลขึ้นอยู่กับ foo_bar จะถูกลบออก ผลักดันการเปิดตัวที่จะยอมรับ ทดสอบการยกเลิกการติดตั้ง (จากผู้ดูแลระบบ / โมดูล) ด้วยสำเนาล่าสุดของฐานข้อมูลการผลิต หากทุกอย่างไปได้ด้วยดีให้ปรับใช้ codebase ใหม่เพื่อการผลิตและยกเลิกการติดตั้ง foo_bar และการพึ่งพาที่นั่น สิ่งนี้จะเรียกใช้การถอนการติดตั้งในโมดูลต่าง ๆ ทำความสะอาดฐานข้อมูล ใน RCS (git) ให้เตรียมรีลีสใหม่ที่มีการลบรหัสจริง ปรับใช้เพื่อยอมรับว่าเราทดสอบว่าไม่มีสิ่งใดขึ้นอยู่กับสิ่งนี้โดยบังเอิญ (โมดูลที่น่าเกลียดหรือฟังก์ชั่นชุดรูปแบบรวมถึงไฟล์โดยตรงจากโมดูลอื่น ๆ CSS, JS หรือไฟล์ภาพที่สะดุดตาที่สุด) หากยอมรับให้ปรับใช้รีลีสใหม่กับการผลิต การผลิตในขณะนี้มีฐานข้อมูลที่สะอาดและ codebase ปัญหาที่ฉันไม่สามารถมองเห็นวิธีการแก้ปัญหาคือมันต้องมีสองรุ่น …

17 nodes  deployment 

ฉันไม่ชอบโซลูชัน "เว็บไซต์โคลนนิ่ง " ที่บอกเป็นนัยถึงการทุ่มตลาดฐานข้อมูลและนำเข้าการถ่ายโอนข้อมูลนี้ในสภาพแวดล้อมอื่น สิ่งนี้ดูเหมือนจะไม่เหมือนโลกแห่งการปรับใช้อินสแตนซ์ต่าง ๆ ของเว็บไซต์เดียวกัน (staging / prod / dev / etc) ด้วย D7 เรามักจะใช้โปรไฟล์ที่กำหนดเองและใช้ drush เพื่อติดตั้งเว็บไซต์จากโปรไฟล์เหล่านี้ (และอาจใช้ฟีเจอร์สำหรับการซิงโครไนซ์ไซต์ในภายหลัง) สิ่งนี้ทำให้เรามีการติดตั้งใหม่ไม่มีเนื้อหาการทดสอบ แต่การแชร์การตั้งค่าที่สำคัญ การซิงโครไนซ์เนื้อหาทั่วไปจะทำได้ด้วยการโอนย้ายตัวอย่างเช่น ฉันพยายามจัดการอินสแตนซ์ D8 หลายตัวที่ใช้โปรไฟล์การติดตั้งร่วมกัน เป้าหมายสุดท้ายคือการแบ่งปันและซิงค์การกำหนดค่าไซต์ และการติดตั้งทุกครั้งจะมี UUID ของไซต์ที่แตกต่างกัน ฉันไม่ประสบความสำเร็จในการบังคับใช้system.site uuidตัวแปร config ในเวลาติดตั้ง (แน่นอนว่าฉันสามารถเปลี่ยนค่าได้ในภายหลัง แต่สำหรับฉันดูเหมือนว่ามันสายเกินไปและวัตถุทั้งหมดถูกสร้างขึ้นด้วย UUID ที่แตกต่างกันซึ่งทำให้การประสานครั้งแรกเป็นฝันร้ายซึ่งเนื้อหาเริ่มต้นบางอย่างต้องถูกลบหรือภาษาเริ่มต้นขัดข้องการซิงค์เนื่องจากไม่สามารถลบออกได้ ฯลฯ ) ในการบังคับใช้ UUID นี้ฉันพยายามใช้ไฟล์ settings.php ที่สร้างขึ้นโดยมี$config['system.site']['uuid']ค่าอยู่ภายในนั้นล้มเหลวอย่างมาก (การตั้งค่านั้นถูกข้ามไปโดยสิ้นเชิง ฉันยังดูโปรไฟล์การติดตั้งการกำหนดค่าซึ่งฉันไม่เข้าใจโดยเฉพาะอย่างยิ่งวิธีผสมโซลูชันนี้กับโปรไฟล์การติดตั้งอื่น ดังนั้นคำถามคืออะไรเป็นวิธีที่ดีที่สุดในการปรับใช้ไซต์สดจากโปรไฟล์การติดตั้ง: โดยไม่ต้อง "โคลนไซต์" …

15 8  configuration-management  deployment 

ฉันสงสัยว่ามีโมดูลที่มีอยู่ที่สามารถช่วยในเรื่องหรือไม่ ฉันไม่ได้กำลังมองหาโมดูลแคช (เช่น Boost หรือ Varnish) แต่เป็นวิธีการส่งออกเว็บไซต์ทั้งหมดของฉัน (หรือเฉพาะบางหน้า) เป็นแบบคงที่ แนวคิดคือฉันต้องการเว็บเซิร์ฟเวอร์ของฉันจะง่ายและเบาและจะให้บริการไฟล์คงที่เท่านั้น (html / css / js) - ไม่มีฐานข้อมูลในการผลิตไม่มีเอ็นจิ้น php จะติดตั้งบนเซิร์ฟเวอร์ เอ็นจิ้น Drupal ทั้งหมดจะอยู่บนเซิร์ฟเวอร์อื่นการส่งออกจะกระทำในแต่ละครั้งที่เพิ่ม / แก้ไข / เปลี่ยนโหนดหรือมุมมองและไฟล์ html ชุดใหม่จะถูกสร้างขึ้นในโครงสร้างไดเรกทอรี ไฟล์เหล่านี้จะถูกคัดลอกไปยังไซต์การผลิตที่จะให้บริการเสมอและมีเพียงไฟล์แบบคงที่เท่านั้นไม่มี. htaccess ที่จะตรวจสอบคำขอหากมีไฟล์อยู่ ฯลฯ มีโมดูลสำหรับสิ่งนั้นหรือวิธีแก้ปัญหาที่สามารถทำได้ด้วย Drupal ขอบคุณ

12 theming  importing-exporting  deployment 

เงื่อนไขที่ฉันแปลที่ "การแปลส่วนต่อประสานกับผู้ใช้" / admin / config / region / แปลไม่สามารถส่งออกได้โดย "การจัดการการกำหนดค่า" / admin / config / development / configuration สำหรับฉัน ฉันพลาดอะไรไปรึเปล่า? ผมอยากจะทำให้กระบวนการนี้ด้วยหรือhook_update_Ndrush cim -y วิธีที่เหมาะสมในการปรับใช้ "การแปลส่วนต่อประสานผู้ใช้" ใน Drupal 8 โดยอัตโนมัติคืออะไร ฉันควรทำยังhook_update_N()ไงดี? ฉันควรสร้างmytranslations.poไฟล์ที่กำหนดเองในโฟลเดอร์ภาษาหรือไม่ ฉันเห็นว่ามีสิ่งlocale_translate_batch_import_files()ที่อาจใช้

12 8  i18n-l10n  deployment 

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

9 drush  deployment  composer  8 

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

8 deployment 

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

8 deployment  staging