การปรับใช้ WordPress อย่างต่อเนื่องและการควบคุมเวอร์ชันด้วย Bitbucket

เอาล่ะคน ถึงเวลาที่จะ 'ยอมรับ

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

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

อย่างไรก็ตาม หากเว็บไซต์ล่มและมีคนดูอยู่ที่นั่น พวกเขาจะส่งเสียงอย่างแน่นอน

การปรับใช้ WordPress อย่างต่อเนื่องผิดพลาด

เข้าสู่ไซต์การแสดงละคร ทำซ้ำการติดตั้ง WordPress (อย่างน้อยก็ในทางทฤษฎี) ซึ่งสามารถเปลี่ยนแปลงได้ จากนั้นทำอีกครั้งบนไซต์สดเมื่อทุกอย่างได้รับการยืนยันแล้วว่าใช้งานได้ แม้ว่าผู้เยี่ยมชมจะเงียบลง แต่ก็เริ่มทำให้เรานักพัฒนาส่งเสียงบางอย่าง ทันใดนั้น เราจำเป็นต้องติดตามไซต์สองแห่ง ตรวจสอบให้แน่ใจว่ามีการซิงค์โค้ดระหว่างไซต์ทั้งสองด้วยตนเอง และทดสอบทุกอย่างอีกครั้งเพื่อให้แน่ใจว่าโค้ดทำงานบนไซต์ที่ใช้งานจริง รายการยาวและยุ่งเหยิงของ "ตรวจสอบให้แน่ใจว่าได้เปลี่ยนแปลงสิ่งนี้" และ "ตรวจสอบให้แน่ใจว่าได้สลับสิ่งนี้ในไซต์การแสดงละครก่อนที่จะคัดลอกโค้ด" อย่างน้อยก็เป็นเรื่องที่น่าปวดหัว การสำรองข้อมูลของระบบนี้เป็นฝันร้ายเช่นกัน—โฟลเดอร์จำนวนมากที่ชื่อว่า “my-theme-staging-1” และ “my-theme-live-before-menu-restyle-3” เป็นต้น

จะต้องมีวิธีที่ดีกว่าและมี

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

แม้ว่าโค้ดเบสจะสะอาดกว่ามาก แต่ปัญหายังคงอยู่จากการปรับใช้จริง และสร้างความมั่นใจว่าไซต์ที่เป็นปัญหานั้นใช้โค้ดล่าสุด—ป้อนโอกาสสำหรับข้อผิดพลาดของมนุษย์ ยังคงใช้การอัพโหลด FTP ด้วยตนเองเขียนทับโค้ดก่อนหน้านั้นไม่ค่อยดีนัก ในขณะที่บริการ CI/CD อื่นๆ มีอยู่ หลายๆ บริการมาพร้อมกับป้ายราคาที่คุ้มค่าและการตั้งค่าจำนวนมาก—การกำหนดค่าเซิร์ฟเวอร์ใหม่ โดยอาศัยบริการอื่นสำหรับเว็บไซต์ที่ง่ายที่สุด เรียนรู้ "วิธีการทำสิ่งต่างๆ" ทั้งหมดของบริการอื่นๆ และทั้งหมด นิสัยแปลก ๆ ที่มาพร้อมกับมัน

ในขณะที่การตั้งค่าที่คล้ายกันในบทช่วยสอนนี้สามารถทำได้ด้วย GitHub/GitLab และบริการอื่นๆ ฉันได้ใส่ไข่ลงในตะกร้า Atlassian ก่อนหน้านี้แล้วเนื่องจากมีที่เก็บส่วนตัวฟรี (ซึ่งเป็นข้อเสนอล่าสุดจาก GitHub เท่านั้น) เมื่อ Bitbucket เปิดตัวบริการ ไปป์ไลน์และการปรับใช้ ของตน อนุญาตให้ใช้โค้ดใหม่ในการปรับใช้กับไซต์การแสดงละครหรือไซต์ที่ใช้งานจริงโดยอัตโนมัติ (หรือไซต์อื่นใดในระหว่างนั้น) โดยไม่ต้องอัปโหลดซ้ำผ่าน FTP หรือใช้บริการภายนอก ตอนนี้ Devs สามารถใช้ค่าของ source control ทั้งหมดในการพัฒนา WordPress ของพวกเขา และส่งการเปลี่ยนแปลงเหล่านั้นไปยังปลายทางที่เหมาะสมได้ทันทีโดยไม่ต้องคลิกหรือกดแป้นพิมพ์เพิ่มเติม พร้อมสถานะของทุกสิ่งที่มองเห็นได้ในแดชบอร์ดเดียว สิ่งนี้ทำให้มั่นใจได้ว่าทุกอย่างจะซิงค์กัน และช่วยให้คุณทราบได้อย่างชัดเจนว่าแต่ละไซต์กำลังเรียกใช้โค้ดใด นอกจากนี้ ราคาสำหรับนาทีบิลด์ของ Bitbucket นั้นไม่แพงอย่างไม่น่าเชื่อ—ฟรี 50 นาทีต่อเดือนและตัวเลือกสำหรับแผน "ฟรีเมื่อเกินกำหนด"

ต้องใช้เวลาเริ่มต้นเล็กน้อยในการหาวิธีใช้สาขาและคุณสมบัติอื่นๆ ของการควบคุมแหล่งที่มาให้ดีที่สุดในรุ่นใหม่นี้และรายละเอียดเฉพาะของการตั้งค่า Bitbucket Pipelines นี่คือกระบวนการที่ฉันใช้เพื่อเริ่มโครงการ WordPress ใหม่ ฉันจะไม่ลงรายละเอียดทั้งหมดเกี่ยวกับการตั้งค่า git และการติดตั้ง WordPress เนื่องจากแหล่งข้อมูลที่ยอดเยี่ยมสำหรับสิ่งนั้นเป็นเพียงการค้นหาโดย Google ในที่สุด การไหลของเนื้อหาจะเป็นดังนี้:

กิจวัตร Depoyment ของ Alexa Green WordPress

ขั้นตอนที่อธิบายไว้ที่นี่ควรดำเนินการตามความจำเป็น:

บนเซิร์ฟเวอร์ของลูกค้า

ตั้งค่าโดเมนสำหรับไซต์ที่ใช้งานจริง (เช่น clientsite.com) และโดเมนย่อยสำหรับการจัดเตรียม (เช่น staging.clientsite.com)

ติดตั้ง WordPress ทั้งในไซต์สดและโดเมนย่อยการแสดงละคร สามารถทำได้ผ่าน cPanel/Softaculous (หากโฮสต์ของลูกค้ามีสิ่งนี้) หรือโดยการดาวน์โหลดจาก wordpress.org ตรวจสอบให้แน่ใจว่ามีฐานข้อมูลแยกต่างหากสำหรับการถ่ายทอดสดและการแสดงละครตามลำดับ

บน Bitbucket.com

ตั้งค่าที่เก็บใหม่ รวม .README เพื่อให้เราก้าวไปข้างหน้า

ในที่เก็บ การตั้งค่า > ไปป์ไลน์ > การตั้งค่า แล้วเลือก เปิดใช้งานไปป์ไลน์

ใน การตั้งค่า > ไปป์ไลน์ > ตัวแปรที่เก็บ ให้ป้อนข้อมูลต่อไปนี้:

 Name: FTP_username Value: The client FTP username

 Name: FTP_password Value: The client FTP password 

กลับไปที่ Pipelines > Settings และคลิกปุ่ม Configure bitbucket-pipelines.yml เลือก PHP เป็นภาษาในหน้าต่อไปนี้ คุณจะต้องใช้บางอย่างเช่นรหัสต่อไปนี้ ตรวจสอบให้แน่ใจว่าได้แทนที่เวอร์ชัน PHP ด้วยสิ่งที่คุณใช้บนเซิร์ฟเวอร์ของไคลเอ็นต์ และเซิร์ฟเวอร์ URL/FTP ด้วย URL ของไซต์ไคลเอ็นต์ (การใช้งานจริงและการจัดเตรียม) / เซิร์ฟเวอร์ FTP

 image: php:7.1.29 pipelines: branches: master: - step: name: Deploy to production deployment: production script: - apt-get update - apt-get -qq install git-ftp - git ftp init --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com main-dev: - step: name: Deploy to staging deployment: staging script: - apt-get update - apt-get -qq install git-ftp - git ftp init --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com/staging.clientsite.com 

คลิก คอมมิตไฟล์ ตอนนี้การตั้งค่าไปป์ไลน์จะได้รับการคอมมิตและเรียกใช้

หากทุกอย่างปรับใช้ได้สำเร็จ ให้กลับไปแก้ไขไฟล์ bitbucket-pipelines.yml (คุณสามารถเข้าถึงได้ผ่าน Pipelines > Settings และ View bitbucket-pipelines.yml ) คุณจะต้องแทนที่ทั้งสองที่ที่ระบุว่า git ftp init ด้วย git ftp push และบันทึก/กระทำ เพื่อให้แน่ใจว่ามีการอัปโหลดเฉพาะไฟล์ที่เปลี่ยนแปลง ซึ่งช่วยให้คุณประหยัดเวลาในการสร้าง ไฟล์ bitbucket-pipelines.yml ของคุณควรอ่านได้ดังนี้:

 image: php:7.1.29 pipelines: branches: master: - step: name: Deploy to production deployment: production script: - apt-get update - apt-get -qq install git-ftp - git ftp push --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com main-dev: - step: name: Deploy to staging deployment: staging script: - apt-get update - apt-get -qq install git-ftp - git ftp push --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com/staging.clientsite.com 

เพิ่มสาขาที่เรียกว่า main-dev

บนเครื่องท้องถิ่นของคุณ

โคลนที่เก็บลงในไดเร็กทอรีว่างที่คุณต้องการใช้สำหรับการติดตั้งในเครื่อง ตรวจสอบสาขา main-dev

ตั้งค่าการติดตั้ง WP ภายในเครื่องในไดเร็กทอรีนี้ มีเครื่องมือมากมายสำหรับสิ่งนี้—ในเครื่องโดย Flywheel, MAMP, Docker ฯลฯ ตรวจสอบให้แน่ใจว่าทุกอย่างเหมือนกัน (เวอร์ชัน WordPress, เวอร์ชัน PHP, Apache/Nginx ฯลฯ) กับสิ่งที่ทำงานบนเซิร์ฟเวอร์ของไคลเอ็นต์

เพิ่ม .gitignore ที่มีลักษณะดังนี้ โดยพื้นฐานแล้วเราต้องการให้ Git ละเว้นทุกอย่างยกเว้นเนื้อหา wp (เพื่อป้องกันปัญหาการติดตั้งระหว่างการติดตั้ง) คุณอาจต้องการเพิ่มกฎของคุณเองสำหรับการละเว้นไฟล์สำรองขนาดใหญ่และไอคอนที่สร้างโดยระบบและไฟล์ DS_Store

 # Ignore everything * # But not .gitignore !*.gitignore # And not the readme !README.md # But descend into directories !*/ # Recursively allow files under subtree !/wp-content/** # Ignore backup files # YOUR BACKUP FILE RULES HERE # Ignore system-created Icon and DS_Store files Icon? .DS_Store # Ignore recommended WordPress files *.log .htaccess sitemap.xml sitemap.xml.gz wp-config.php wp-content/advanced-cache.php wp-content/backup-db/ wp-content/backups/ wp-content/blogs.dir/ wp-content/cache/ wp-content/upgrade/ wp-content/uploads/ wp-content/wflogs/ wp-content/wp-cache-config.php # If you're using something like underscores or another builder: # Ignore node_modules node_modules/ # Don't ignore package.json and package-lock.json !package.json !package-lock.json

บันทึกและคอมมิต .gitignore

ทำการเปลี่ยนแปลงและดำเนินการตามนั้น

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

การรวม main-dev เข้ากับ master จะทำให้เกิดการเปลี่ยนแปลงการแสดงละครทั้งหมด คุณสามารถตรวจสอบสถานะของไปป์ไลน์และการปรับใช้บน repo ได้ที่ Bitbucket.org

การซิงค์ฐานข้อมูล WordPress ระหว่างการติดตั้ง

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

สำหรับการซิงค์ฐานข้อมูลระหว่างการติดตั้ง WordPress มีหลายตัวเลือก ตามเนื้อผ้า คุณสามารถอัปเดตฐานข้อมูลโดยการนำเข้า/ส่งออกผ่าน phpmyadmin สิ่งนี้ค่อนข้างยุ่งยาก เนื่องจากไม่สามารถอัปเดตบางสิ่งที่ต้องอัปเดตได้ เช่น ลิงก์ถาวรในเนื้อหาโพสต์ การใช้วิธีนี้ เครื่องมือโปรดคือปลั๊กอิน Velvet Blues Update URLs ซึ่งคุณสามารถใช้เพื่อค้นหา/แทนที่อินสแตนซ์ของ URL ไซต์เก่า (เช่น https://staging.clientsite.com) ไปยัง URL ของไซต์ใหม่ ( เช่น https://clientsite.com) คุณยังสามารถใช้สิ่งนี้กับเส้นทางและสตริงที่สัมพันธ์กัน วิธีนี้ทำให้เหลือพื้นที่สำหรับข้อผิดพลาดของมนุษย์เป็นจำนวนมาก หากสตริงที่แทนที่เขียนผิด อาจทำให้ทั้งไซต์เสียหายและไม่สามารถใช้ปลั๊กอิน/เข้าถึงแดชบอร์ดได้

แม้ว่าปลั๊กอินอย่าง All-in-One WP Migration จะนำเสนอฟีเจอร์การค้นหา/แทนที่แบบสำเร็จรูปและใช้งานง่ายอย่างเหลือเชื่อ แต่ก็ยังนำไฟล์มาทับด้วย ดังนั้นจึงยกเลิกค่าของเวิร์กโฟลว์ไปป์ไลน์ทั้งหมดของเรา นอกจากนี้ เนื่องจากนำเข้า wp-uploads ทั้งหมดอีกครั้ง จึงสามารถส่งผลให้ไฟล์มีขนาดใหญ่และใช้เวลาในการโหลด (ดังนั้นจึงไม่เหมาะสำหรับการย้ายการเปลี่ยนแปลงในการติดตั้ง) ปลั๊กอินแบบนี้สงวนไว้ดีที่สุดสำหรับการสำรองข้อมูลของไซต์ทั้งหมดเพื่อวัตถุประสงค์ในการเก็บถาวร/การรักษาความปลอดภัย

VersionPress ดูเหมือนจะเป็นวิธีแก้ปัญหาที่น่าสนใจ แต่ยังไม่ได้รับการพิสูจน์ในสภาพแวดล้อมการผลิตจำนวนมาก ในตอนนี้ ปลั๊กอินอย่าง WP Sync DB หรือ WP Migrate DB Pro ดูเหมือนจะเป็นโซลูชันที่ดีที่สุดสำหรับการจัดการฐานข้อมูล พวกเขาอนุญาตให้ดึง / ผลักฐานข้อมูลข้ามการติดตั้งในขณะที่ให้ตัวเลือกในการอัปเดต URL และพา ธ โดยอัตโนมัติ พวกเขาสามารถย้ายข้อมูลได้เฉพาะบางตารางเท่านั้น เช่น wp_posts สำหรับเนื้อหาโพสต์เท่านั้น ไม่ต้องเสียเวลากับการนำเข้าผู้ใช้ใหม่และการตั้งค่าทั่วทั้งไซต์ ฉันชอบที่จะดึงออกจากการถ่ายทอดสดเสมอเพื่อให้แน่ใจว่าไม่มีข้อมูลการผลิตใดถูกเขียนทับ นี่คือตัวอย่างการตั้งค่าหากคุณใช้ WP Sync DB (มีคำแนะนำเพิ่มเติมใน WP Sync DB github):

1. บนไซต์สด: ตั้งค่า WP Sync DB โดยเปิดใช้งานการตั้งค่า "Allow Pull from this repository"
2. บนไซต์การแสดงละคร: ตั้งค่า WP Sync DB ด้วยการตั้งค่า Pull from Live ตั้งชื่อมันว่า
3. ในการตั้งค่า dev ในพื้นที่ของคุณ: ตั้งค่า WP Sync DB ด้วยการตั้งค่า Pull จาก Live ตั้งชื่อมันว่า "live-to-dev"

คุณยังอาจต้องการตั้งค่ากฎ "dev-to-staging" แบบพุช และตรวจสอบการตั้งค่าไซต์ staging เพื่ออนุญาตให้เขียนทับฐานข้อมูล

ห่อ

ฉันพบว่าวิธีการเหล่านี้มักจะใช้ได้กับกรณีการใช้งานส่วนใหญ่ ทั้งในการพัฒนาเว็บไซต์ WordPress ใหม่และสำหรับการออกแบบใหม่/ปรับแต่งไซต์ที่ใช้งานได้แล้ว

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

แม้ว่าจะมีช่องว่างสำหรับการปรับปรุงเพื่อนำเวิร์กโฟลว์การควบคุมแหล่งที่มามาสู่การจัดการฐานข้อมูลมากขึ้น จนกว่าเครื่องมือเช่น VersionPress จะถูกใช้งานมากขึ้นในสภาพแวดล้อมการผลิต วิธีการเลือกดึง/ผลักของฐานข้อมูลผ่าน WP Sync DB หรือ WP Migrate DB Pro ดูเหมือน เพื่อเป็นวิธีการรับมือที่ปลอดภัยที่สุด อยากรู้ว่าอะไรใช้ได้ผลสำหรับเวิร์กโฟลว์ WordPress ของคุณ หรือถ้าหลังจากนี้ คุณก็ควรคว้าโค้ด lasso และ cowboy เอาไว้!