กลยุทธ์การปรับใช้ที่ดีที่สุดคืออะไร

82

การตั้งค่า Magento store ไม่เพียง แต่เป็นเรื่องของการพัฒนาส่วนขยายที่ติดตั้งได้เอง แต่ยังต้องใช้การดำเนินการ "การป้อนข้อมูลด้วยตนเอง" จำนวนมากเช่นการสร้างแอททริบิวการแก้ไขขั้นสุดท้ายหมวดหมู่ผลิตภัณฑ์ผลิตภัณฑ์กฎราคาหน้า CMS เป็นต้น การเปลี่ยนแปลงการกำหนดค่าระบบ

ฉันต้องการความช่วยเหลือจากคุณในการจัดทำกลยุทธ์ที่ดีที่สุดในการปรับใช้ร้านค้า Magento ตั้งแต่การพัฒนาไปจนถึงการจัดเตรียมและสภาพแวดล้อมการผลิต

กลยุทธ์หนึ่งของฉันคือการเขียน "ปรับใช้โมดูล" ซึ่งสร้างเอนทิตีที่กล่าวถึงข้างต้นโดยทางโปรแกรม แต่มันเป็นงานที่ต้องใช้เวลานานมาก

เมื่อเร็ว ๆ นี้ฉันเริ่มใช้ Selenium IDE เพื่อทำซ้ำงานธุรการ แต่เวลาที่ใช้ในการตั้งค่าชุดทดสอบทั้งหมดไม่ไกลจากที่กล่าวมาข้างต้น

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

ดังนั้น:

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

ขอขอบคุณ!

deploy admin entities

— Alessandro Ronchi
แหล่งที่มา

สิ่งนี้อาจชี้ไปที่ความต้องการแท็กหรือหมวดหมู่แท็กอื่น คุณเป็นร้านค้าแบบครั้งเดียวหรือคุณกำลังมองหาคำแนะนำทั่วไปในฐานะผู้ให้บริการหรือไม่? หากหลังคำตอบใด ๆ จะต้องมีการ peppered ด้วย "ขึ้นอยู่กับการควบคุมลูกค้าต้องการมากกว่าข้อมูลเอนทิตี"

— benmarks

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

— Alessandro Ronchi

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

— ProxiBlue

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

— Alessandro Ronchi

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

— ProxiBlue

39

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

ความคิดที่อยู่เบื้องหลังสิ่งนี้คือหากเว็บไซต์จำเป็นต้องติดตั้งใหม่โดยใช้ฐานข้อมูลใหม่ทุกอย่างก็กลับมาเหมือนที่คุณมี สิ่งนี้ยังช่วยให้ฉันอัปเดตไซต์ uat เป็นระยะด้วยสำเนา live db โมดูลใน uat จะทำงานต่อไปในขณะที่พวกเขาสล็อตในการกำหนดค่าของพวกเขาอีกครั้ง

การเปลี่ยนแปลงอัตราไปรษณีย์กฎรถเข็น ฯลฯ (โดยทั่วไปสิ่งที่ลูกค้าจัดการด้วยตนเองในผู้ดูแลระบบ) ถือว่าเป็น 'ข้อมูลระเหย' และไม่ได้ถูกสคริปต์ รวมถึงข้อมูลผลิตภัณฑ์ ลูกค้ามีตัวเลือกและได้รับการสนับสนุนให้ทดสอบการนำเข้าใหม่บนไซต์ uat ก่อน

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

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

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

1

ฉันเห็นด้วยกับ dedmeet เมื่อคุณเรียนรู้วิธีสคริปต์การอัปเดตทั้งหมดอาจเป็นงานเริ่มแรก แต่ถ้าคุณต้องใช้การอัปเดตการกำหนดค่าด้วยตนเองสำหรับนักพัฒนา 3-4 คนการแสดงละคร uat และถ่ายทอดสดการประสานงานและงานจริงจะใช้เวลานานกว่ามาก เวิร์กโฟลว์ของเราคล้ายกันมาก: หากต้องการกำหนดค่าสำหรับส่วนขยาย (นำมาใช้ใหม่) ให้ใส่ไว้ที่นั่น หากการกำหนดค่าเป็นไคลเอ็นต์เฉพาะให้วางไว้ในส่วนขยายเฉพาะของโครงการ หนึ่งในข้อยกเว้นบางประการคือกฎเกวียนซึ่งไม่สนุกในการอัปเดต / สร้างเลย

— Matthias Zeis

1

ฉันเพิ่งเปิดตัวโมดูลที่ช่วยในการสร้างสคริปต์การกำหนดค่าที่ต้องการจึงกำจัดงานทางโลกของการสร้างสคริปต์การติดตั้งด้วยตนเอง โมดูลใช้การแสดงตารางของตาราง core_config_data เพื่ออนุญาตให้เลือกค่าการกำหนดค่าเพื่อส่งออก ทำให้ชีวิตของฉันง่ายขึ้นนิดหน่อยและฉันหวังว่ามันจะใช้ได้ผลกับคนอื่น proxiblue.com.au/blog/magento-config-data-generator

— ProxiBlue

27

ฉันได้รับการวิจัยหลายเดือนที่ผ่านมา นี่คือเว็บไซต์ที่คุณสามารถอ้างอิงได้

~~Magento Base URL และการติดตั้ง dev / staging การ~~
พัฒนาและการใช้งาน
วีโอไอพีคู่มือ Gento และขั้นตอนการทำงาน
รวดเร็วยิ่งกว่าการทิ้งฐานข้อมูล MySQL วีโอไอพีสำหรับการแยก

— OğuzÇelikdemir
แหล่งที่มา

1

ขอบคุณฉันจะอ่านพวกเขาทั้งหมดและกลับมาพร้อมกับข้อควรพิจารณาบางอย่าง

— Alessandro Ronchi

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

— Alessandro Ronchi

เรียนอเลสซานโดรฉันอยากจะเห็นวิธีการของคุณซึ่งฉันกำลังมองหาเทคนิคที่สะดวกสบายมากขึ้นเช่นกัน!

— OğuzÇelikdemir

18

ฉันอยากจะขอบคุณทุกคนเพราะการพิจารณาของคุณเป็นแรงบันดาลใจและผลักดันให้ฉันพัฒนาส่วนขยายที่เรียกว่า "Mageploy" ด้วยความตั้งใจที่จะแก้ไขปัญหาของการรักษาสภาพแวดล้อมที่แตกต่างกันให้ตรงกัน

http://www.mageploy.com

Mageploy ยังคงต้องมีการขยายเอกสารที่ดีและการทดสอบอย่างเต็มที่แม้ว่าฉันจะใช้มันในโครงการที่มีประโยชน์

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

ความนับถือ

— Alessandro Ronchi
แหล่งที่มา

7

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

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

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

— พอล
แหล่งที่มา

1

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

— benmarks

การแบ่งปันไซต์การจัดเตรียมกับลูกค้าเพื่อร่วมมือกันในการกำหนดค่าเป็นสิ่งที่ดีในทางทฤษฎี ในทางปฏิบัติลูกค้าไม่ได้บอกคุณทุกสิ่งที่พวกเขาเปลี่ยน 99% ของเวลาซึ่งทำให้ง่ายต่อการทำให้บางสิ่งผิดพลาด เราอาจอนุญาตให้ลูกค้าทำงานกับสิ่งต่าง ๆ ตามกฎรถเข็นหมวดหมู่ผลิตภัณฑ์หรือสิ่งที่คล้ายกัน แต่เราจะไม่ปล่อยให้ลูกค้าเข้าไปยุ่งเกี่ยวกับการกำหนดค่า

— Matthias Zeis

6

ในความเห็นของฉันการสร้างและแก้ไขคุณลักษณะหมวดหมู่ผลิตภัณฑ์กฎราคาไม่มีส่วนเกี่ยวข้องกับ "กลยุทธ์การปรับใช้งาน" รายการทั้งหมดเหล่านี้มีเอกลักษณ์เฉพาะของร้านค้าและในกรณีส่วนใหญ่ต้องการการวิเคราะห์และวิจัยผลิตภัณฑ์ที่เหมาะสมสำหรับคุณ กำลังจะขาย

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

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

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

— Alessandro Ronchi

อาตกลงนั่นทำให้ชัดเจนมากขึ้น

— Rutger

สมมติว่าเรากำลังสร้างเว็บไซต์ใหม่ที่สมบูรณ์แบบดังนั้นจึงไม่มีปัญหาเกี่ยวกับข้อมูลเก่า ฯลฯ เกือบทุกครั้งที่ devs ทั้งหมดของเราใช้ฐานข้อมูลเดียวกันเพื่อการพัฒนา นั่นแก้ปัญหาได้มากมาย สำหรับกรณีอื่น ๆ ฉันไม่มีวิธีแก้ปัญหาที่ดีกว่า (ยัง) กว่าจะเขียนขั้นตอนทั้งหมดที่จำเป็นในโร้ดแม็พ / สคริปต์และนำกลับมาใช้ใหม่ทั้งหมดหลังจากรวมเข้าด้วยกัน หากมีเพียงคนเดียวเท่านั้นที่รับผิดชอบการตั้งค่าผู้ดูแลระบบ "magento core" สิ่งเหล่านี้ไม่ควรทำในหลาย ๆ ขั้นตอน ฉันเคยพบสิ่งนี้ แต่ไม่เคยลองเลยtinybrick.com/magento-modules/admin-tools/ …

— Rutger

2

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

สำหรับการพัฒนา: PhpStorm IDE พร้อมปลั๊กอินMagicento
สำหรับการปรับใช้: Magentifyสูตร Capistrano สำหรับ Magento

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

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

— Alessandro Ronchi