Magento2 - การปรับใช้ในท้องถิ่น / การแสดงละคร / การผลิต & gitignore

นี่อาจเป็นการสนทนามากกว่าหนึ่งคำถาม

ฉันต้องการทราบนโยบายการปรับใช้ที่คุณปฏิบัติตามด้วยสภาพแวดล้อมแบบMagento2 และในพื้นที่ > การจัดเตรียม > การผลิต

หลังจากความพยายามบางอย่างเราได้ตัดสินใจวิธีที่ดีที่สุด (หรืออย่างน้อยที่สุดวิธีที่ทึบที่สุด) คือไฟล์ gitignore นี้รวมถึงโฟลเดอร์ผู้ขายใน git

.DS_Store
/.buildpath
/.cache
/.metadata
/.project
/.settings
atlassian*
/nbproject
/sitemap
/sitemap.xml
/.idea
/.gitattributes
/app/config_sandbox
/app/etc/config.php
/app/etc/env.php
/app/code/Magento/TestModule*
/lib/internal/flex/uploader/.actionScriptProperties
/lib/internal/flex/uploader/.flexProperties
/lib/internal/flex/uploader/.project
/lib/internal/flex/uploader/.settings
/lib/internal/flex/varien/.actionScriptProperties
/lib/internal/flex/varien/.flexLibProperties
/lib/internal/flex/varien/.project
/lib/internal/flex/varien/.settings
/node_modules
/.grunt
/pestle.phar
/pub/media/*.*
!/pub/media/.htaccess
/pub/media/catalog/*
!/pub/media/catalog/.htaccess
/pub/media/customer/*
!/pub/media/customer/.htaccess
/pub/media/downloadable/*
!/pub/media/downloadable/.htaccess
/pub/media/import/*
!/pub/media/import/.htaccess
/pub/media/theme/*
/pub/media/theme_customization/*
!/pub/media/theme_customization/.htaccess
/pub/media/wysiwyg/*
!/pub/media/wysiwyg/.htaccess
/pub/media/tmp/*
!/pub/media/tmp/.htaccess
/pub/media/captcha/*
/pub/static/***
!/pub/static/.htaccess

/var/*
!/var/.htaccess

.unison*
/sync.sh

ดังนั้นเราจึงเรียกใช้ผู้แต่งในสภาพแวดล้อมท้องถิ่น: เนื่องจากส่วนขยายใหม่ใด ๆ หรือการอัปเกรดซอฟต์แวร์ได้รับการทดสอบในท้องถิ่นจากนั้นตรวจสอบและยืนยัน เราอาจจะรวมไฟล์app / etc / config.phpไว้ใน git ด้วย แต่ไฟล์นั้นจะถูกเขียนใหม่เมื่อทำงานsetup:upgradeใช่ไหม?

การรวมผู้ขายหมายความว่าขนาดพื้นที่เก็บข้อมูลจะใหญ่กว่า (อาจ) แนะนำ แต่ด้วยวิธีนี้เมื่อปรับใช้รหัสเราเพิ่งเรียกใช้ลำดับ:

bin/magento setup:upgrade
bin/magento setup:di:compile (optional)
bin/magento setup:static-content:deploy

ข้อมูลที่เกี่ยวข้อง: http://www.damianculotta.com.ar/magento/gitignore-y-la-estrategia-de-deploys-en-magento2

ดูว่าทำไมเราเลือกคำสั่งคอมไพล์เป็นตัวเลือกMagento 2 - setup: di: compile ?

UPDATE

ความจริงก็คือเรากำลังมีปัญหาบางอย่างเมื่อปรับใช้การเปลี่ยนแปลงรหัสในโครงการ Magento 2 ที่เผยแพร่ของเรา

การเปลี่ยนแปลงทำงานในท้องถิ่น & การจัดเตรียม (ทำเครื่องหมายในทั้งสองโหมด: นักพัฒนา & การผลิต ... แม้ว่าเราจะกำหนดค่าสภาพแวดล้อมในโหมดนักพัฒนาซอฟต์แวร์) แต่บางคนไม่ทำงานในสภาพแวดล้อมการผลิต (ในโหมดการผลิต) ฯลฯ ... ดังนั้นฉันไม่แน่ใจว่าเรากำลังติดตามกลยุทธ์ที่ถูกต้อง ฉันต้องการดูลำดับของคำสั่งที่เหมาะสมและความเกี่ยวข้องของลำดับในคำสั่งนั้น

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

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

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

ฉันพบว่าการปรับใช้ที่ใช้ Git นั้นคุณใช้น้อยกว่าที่เหมาะสมสำหรับ Magento 2 มากกว่าสำหรับ Magento 1 เนื่องจากการประมวลผลล่วงหน้าทั้งหมด การสร้างและการปรับใช้มีความซับซ้อนมากขึ้นและ IMHO ไม่มีวิธีแก้ไขกระบวนการสร้างอัตโนมัติ

สิ่งที่ฉันอยากจะแนะนำ:

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

• เพื่อให้บรรลุนั้นให้แยกบิลด์ออกจากการปรับใช้และทำสิ่งต่อไปนี้ในกระบวนการบิลด์:

  • composer install(การเพิ่มvendorไปยังที่เก็บแทนเป็นไปได้เช่นกัน แต่ถ้าคุณทำเช่นนั้นเพื่อหลีกเลี่ยงการเรียกใช้ผู้แต่งบนเซิร์ฟเวอร์ในระหว่างการปรับใช้ให้ทำในขั้นตอนการสร้างและเก็บcomposer.lockใน repo เท่านั้น)

  • การสร้างรหัส (YMMV):

    bin/magento setup:di:compile
    bin/magento setup:static-content:deploy

  • สร้างที่เก็บถาวร (คนสร้างสิ่งประดิษฐ์ ) จากไดเรกทอรีวีโอไอพีเต็มไม่รวมmediaและvarแต่รวมvendor, pub, และvar/generated var/diเริ่มต้นด้วยmagento-2.2 , var/generatedและvar/diถูกย้ายไปที่generated/codeและgenerated/metadata, ซึ่งทำให้ง่ายต่อการแยกออกจากส่วนที่เหลือvarซึ่งควรถูกละเว้นสำหรับการปรับใช้

• ในการปรับใช้ให้คัดลอกบิวด์การสร้างไปยังเซิร์ฟเวอร์เป้าหมายแยกไปยังไดเร็กทอรีใหม่และ:

  • เชื่อมโยงไดเรกทอรีถาวรเป็นมัน ( media, var/session, var/log, ... )
  • เปิดใช้งานโหมดการบำรุงรักษา
  • สลับรูทเอกสาร (โดยปกติ docroot จะเป็น symlink ไปเป็นรีลีสล่าสุดเปลี่ยนเป็นรีลีสใหม่)
  • ล้างแคช
  • วิ่ง setup:upgrade
  • ปิดใช้งานโหมดการบำรุงรักษา

• กระบวนการปรับใช้นี้สามารถนำไปใช้งานได้อย่างง่ายดายด้วยDeployerซึ่งก็เหมือนกับ Capistrano แต่เป็นใน PHP โซลูชันการปรับใช้แบบเต็มรูปแบบสำหรับ Magento 2 ซึ่งขึ้นอยู่กับตัวปรับใช้สามารถดูได้ที่นี่: https://github.com/mwr/magedeploy2 (ขอบคุณ netz98!) และนี่คืออีกวิธีหนึ่งที่เราใช้: https://github.com/staempfli / magento2 การใช้งานเครื่องมือ

• การเก็บapp/etc/config.phpในที่เก็บเป็นสิ่งที่ดีในการติดตามโมดูลที่เปิดใช้งานและปิดใช้งาน

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

ในใจของฉันรอ Magento 2.2 หรือพยายามที่จะใช้วิธีการที่คล้ายกัน

Magento 2.2 แนะนำการปรับใช้ไปป์ไลน์โดยตัวอย่างเช่นการแยกเซิร์ฟเวอร์บิลด์กับเซิร์ฟเวอร์ที่ใช้งานจริง

นี่คือเอกสารอย่างเป็นทางการ: http://devdocs.magento.com/guides/v2.2/config-guide/deployment/pipeline/

ยิ่งไปกว่านั้นในปัจจุบันฉันใช้ Ansible เพื่อจัดการกับการปรับใช้อัตโนมัติด้วยแม่แบบการกำหนดค่าและการตั้งค่าสภาพแวดล้อมหลายอย่าง