สร้างเวิร์กโฟลว์ CI/CD – ปรับใช้ธีม WordPress โดยอัตโนมัติด้วย GitHub Actions

บทนำ

ในการพัฒนาเว็บสมัยใหม่ มีหลายขั้นตอนที่คุณต้องทำเพื่อสร้างและนำโค้ดไปใช้งานจริง สำหรับธีมหรือปลั๊กอิน WordPress นั่นอาจหมายถึงการติดตั้ง Composer และ/หรือ Node.js การพึ่งพา การคอมไพล์ CSS การทรานสไพล์ JavaScript และการอัปโหลดไฟล์ไปยังเซิร์ฟเวอร์ของคุณ

ในบทความนี้ เราจะสำรวจวิธีปรับปรุงกระบวนการปรับใช้ WordPress โดยใช้ GitHub Actions เราจะสร้างเวิร์กโฟลว์ GitHub Actions เพื่อสร้างและปรับใช้ธีม WordPress โดยอัตโนมัติบนไซต์ Pressidium WordPress ของคุณ

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

ข้อกำหนดเบื้องต้น

• ความเข้าใจพื้นฐานของ Git (การสร้างพื้นที่เก็บข้อมูล การคอมมิตและการพุชโค้ด การสร้างสาขา ฯลฯ)
• ความคุ้นเคยกับอินเทอร์เฟซของ GitHub

“การปรับใช้” ในการพัฒนาเว็บคืออะไร?

การปรับใช้ในการพัฒนาเว็บเป็นกระบวนการ ผลักดันการเปลี่ยนแปลง ไปยังสภาพแวดล้อมระยะไกล ทำให้เว็บไซต์หรือแอปพลิเคชันพร้อมใช้งาน

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

มีหลายวิธีในการส่งไฟล์เว็บไซต์ของคุณไปยังผู้ให้บริการโฮสติ้ง ในกรณีของเรา เราจะใช้ Secure File Transfer Protocol (SFTP) ซึ่งเป็นโปรโตคอลเครือข่ายสำหรับการถ่ายโอนไฟล์ผ่านช่องทางที่ปลอดภัย เช่น SSH ตามชื่อ

การกระทำของ GitHub คืออะไร?

GitHub Actions เป็นแพลตฟอร์มการผสานรวมอย่างต่อเนื่องและการส่งมอบอย่างต่อเนื่อง (CI/CD) ที่ช่วยให้คุณสร้างและปรับใช้ไปป์ไลน์ได้โดยอัตโนมัติ

ในย่อหน้าต่อไปนี้ เราจะสำรวจวิธีสร้างเวิร์กโฟลว์ GitHub Actions เพื่อสร้างและปรับใช้ธีม WordPress โดยใช้ประโยชน์จากผู้ให้บริการโฮสติ้งที่สนับสนุนสภาพแวดล้อมชั่วคราว

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

หากคุณใช้ Pressidium อยู่แล้ว สภาพแวดล้อมการจัดเตรียมจะรวมอยู่ในแผนทั้งหมดฟรี อ่านบทความ KB นี้สำหรับข้อมูลเพิ่มเติม

เวิร์กโฟลว์ GitHub Actions คืออะไร

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

การใช้เวิร์กโฟลว์ GitHub Actions มีประโยชน์มากมาย

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

เริ่มต้นใช้งาน

มาเริ่มต้นเวิร์กโฟลว์แรกของคุณด้วยการสร้างไฟล์ YAML ใหม่ใน .github/workflows/ ในที่เก็บ GitHub ของคุณ เราจะเริ่มด้วยเวิร์กโฟลว์ง่ายๆ เพื่อปรับใช้กับการผลิตโดยอัตโนมัติ ดังนั้นเรามาตั้งชื่อไฟล์นี้ว่า deploy.yml

 # .github/workflows/deploy.yml name: deploy on: push: branches: # Pushing to the `main` branch # will trigger our workflow - main

เราใช้คำหลัก on เพื่อกำหนดว่าเหตุการณ์ใดอาจทริกเกอร์เวิร์กโฟลว์ ในตัวอย่างนี้ เวิร์กโฟลว์จะทำงานเมื่อมีการพุชไปยังสาขา main

เราอาจไม่จำเป็นต้องปรับใช้เลยเมื่อไฟล์บางไฟล์มีการเปลี่ยนแปลง เช่น README.md เราสามารถใช้ on.push.paths-ignore เพื่อแยกรูปแบบพาธของไฟล์

 name: deploy on: push: branches: - main paths-ignore: - 'bin/**' - 'README.m

สร้างงานแรกของคุณ

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

 name: deploy on: [...] jobs: deploy: runs-on: ubuntu-latest steps: [...]

แต่ละงานจะทำงานในสภาพแวดล้อมแบบรันเนอร์ ซึ่งระบุโดย runs-on น ในบล็อก YAML ด้านบน เราใช้ ubuntu-latest ซึ่งเป็นเครื่องเสมือน (VM) ของ Ubuntu Linux ซึ่งโฮสต์โดย GitHub พร้อมกับแอปพลิเคชันรันเนอร์และเครื่องมืออื่นๆ ที่ติดตั้งไว้ล่วงหน้า

คุณสามารถใช้รันเนอร์ที่โฮสต์โดย GitHub หรือโฮสต์รันเนอร์ของคุณเองและปรับแต่งสภาพแวดล้อมที่ใช้ในการรันงาน อย่างไรก็ตาม สิ่งหลังนี้อยู่นอกเหนือขอบเขตของบทความนี้

ตรวจสอบที่เก็บ Git ของคุณ

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

 jobs: deploy: runs-on: ubuntu-latest steps: - name: Checkout # Checkout our repository under `${GITHUB_WORKSPACE}`, # so our workflow can access it uses: actions/checkout@v3 with: # Fetch the entire Git history fetch-depth: 0

เราระบุ fetch-depth เป็น 0 ซึ่งจะส่งผลให้มีการดึงข้อมูลประวัติ Git ทั้งหมด เราต้องการสิ่งนี้เพื่ออัปโหลดเฉพาะไฟล์ที่มีการเปลี่ยนแปลงในการเรียกใช้ครั้งต่อๆ ไป

การสร้างผู้ใช้ SFTP

หากต้องการอัปโหลดไฟล์ไปยังผู้ให้บริการโฮสติ้ง คุณต้องมีรายละเอียดการเชื่อมต่อ SFTP (เช่น โฮสต์ พอร์ตเครือข่าย และพาธ) และผู้ใช้ SFTP

ส่วนใหญ่แล้ว คุณสามารถดูรายละเอียดเหล่านี้และสร้างผู้ใช้ SFTP ผ่านแดชบอร์ดของผู้ให้บริการโฮสติ้ง โฮสต์เว็บบางแห่งจะส่งอีเมลรายละเอียดเหล่านี้ให้คุณด้วย

หากคุณใช้ Pressidium อยู่แล้ว ให้ทำตามขั้นตอนเหล่านี้:

1. เข้าสู่ระบบแผงควบคุม Pressidium ของคุณ
2. เลือกตัวเลือกเมนู เว็บไซต์ จากแถบด้านข้างแดชบอร์ด
3. คลิกที่ชื่อเว็บไซต์ของคุณ
4. ไปที่แท็บ SFTP โดยคลิกลิงก์บนแถบนำทาง
5. จดบันทึกรายละเอียดการ เชื่อมต่อ SFTP ของคุณ
6. สร้าง ผู้ใช้ SFTP ใหม่

วิธีสร้างผู้ใช้ SFTP ใหม่:

1. คลิก ใหม่
2. เลือก สภาพแวดล้อม ( การผลิต หรือ การจัดเตรียม )
3. ระบุ ชื่อผู้ใช้ และ รหัสผ่าน (แนะนำให้ใช้รหัสผ่านที่เดายาก ผสมอักขระละตินตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ ตัวเลข และอักขระพิเศษ)
4. จดบันทึกชื่อผู้ใช้และรหัสผ่านที่คุณป้อน
5. คลิก สร้าง เพื่อสร้างผู้ใช้

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

โฮสต์เว็บไซต์ของคุณด้วย Pressidium

รับประกันคืนเงิน 60 วัน

ดูแผนของเรา

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการเข้าถึงไซต์ Pressidium WordPress ผ่าน SFTP โปรดดูบทความ KB นี้

การจัดเก็บข้อมูลที่ละเอียดอ่อน

คุณสามารถป้อนรายละเอียดการเชื่อมต่อ SFTP และข้อมูลรับรองผู้ใช้ SFTP ได้โดยตรงในเวิร์กโฟลว์ GitHub Actions ของคุณ อย่างไรก็ตาม การจัดเก็บข้อมูลที่ละเอียดอ่อนในที่เก็บข้อมูลของคุณเป็นความคิดที่ไม่ดี

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

วิธีสร้างความลับที่เข้ารหัสสำหรับที่เก็บ:

1. ลงชื่อเข้าใช้บัญชี GitHub ของคุณ
2. ไปที่หน้าหลักของที่เก็บของคุณ
3. ภายใต้ชื่อที่เก็บของคุณ ให้คลิก การตั้งค่า
4. เลือก ความลับ แล้วคลิก การ ดำเนิน การ ใต้ส่วนความปลอดภัยของแถบด้านข้าง
5. คลิกปุ่ม ความลับที่เก็บใหม่
6. พิมพ์ ชื่อ ลับและ ค่า ของมัน
7. คลิก เพิ่มความลับ

คุณควรจบลงด้วยรายการความลับที่คล้ายกับรายการนี้:

• SFTP_HOST ชื่อโฮสต์ของเซิร์ฟเวอร์ SFTP
• SFTP_PORT พอร์ตของเซิร์ฟเวอร์ SFTP
• SFTP_USER ชื่อผู้ใช้ที่จะใช้สำหรับการตรวจสอบสิทธิ์
• SFTP_PASS รหัสผ่านที่ใช้สำหรับการตรวจสอบสิทธิ์

การอัปโหลดไฟล์ผ่าน SFTP

ในการอัปโหลดไฟล์ของคุณผ่าน SFTP คุณสามารถใช้——คุณคาดเดา——อีก GitHub Action

มีไคลเอนต์ SFTP และ GitHub Actions ให้เลือกมากมาย เราใช้ lftp-mirror-action ของเราเอง ซึ่งใช้ lftp ภายใต้ประทุน เครื่องมือถ่ายโอนไฟล์ที่รองรับ SFTP และสามารถถ่ายโอนหลายไฟล์พร้อมกันได้

 - name: Deploy via SFTP uses: pressidium/lftp-mirror-action@v1 with: host: ${{ secrets.SFTP_HOST }} port: ${{ secrets.SFTP_PORT }} user: ${{ secrets.SFTP_USER }} pass: ${{ secrets.SFTP_PASS }} remoteDir: '/demo-www/wp-content/themes/my-theme' options: '--verbose'

การกำหนดค่าอินพุตของ lftp-mirror-action ค่อนข้างตรงไปตรงมา:

• รายละเอียดการเชื่อมต่อ SFTP และข้อมูลรับรองผู้ใช้ SFTP ของคุณสามารถเข้าถึงได้ผ่านบริบท secrets (เช่น ${{ secrets.SFTP_HOST }} )
• remoteDir คือพาธไปยังไดเร็กทอรีของธีมของคุณ
• ตัวเลือก '--verbose' จะเปิดใช้งานเอาต์พุตแบบละเอียด ซึ่งจะบันทึกการถ่ายโอนไฟล์ทั้งหมด (มีประโยชน์สำหรับการแก้ไขปัญหา)

บน Pressidium เส้นทางจะมีรูปแบบดังนี้:

• YOUR_INSTALLATION_NAME-www/ เป็นเส้นทางรูทของ สภาพ แวดล้อมการใช้งานจริง
• YOUR_INSTALLATION_NAME-dev-www/ เป็นเส้นทางรูทของสภาพแวดล้อม การจัดเตรียม

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

คุณสามารถเลือกสร้างไฟล์ . .lftp_ignore ในที่เก็บของคุณ รวมถึงรูปแบบไฟล์ใดๆ ที่คุณต้องการยกเว้นจากการปรับใช้

นี่คือตัวอย่างลักษณะที่ปรากฏ:

 ## Directories to ignore .vscode/** .env.** .git/ .github/ ## Files to ignore .gitignore package.json package-lock.json composer.json composer.lock

วางมันทั้งหมดเข้าด้วยกัน

 name: deploy on: push: branches: - main paths-ignore: - 'bin/**' - 'README.md' jobs: deploy: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 with: fetch-depth: 0 - name: Deploy via SFTP uses: pressidium/lftp-mirror-action@v1 with: host: ${{ secrets.SFTP_HOST }} port: ${{ secrets.SFTP_PORT }} user: ${{ secrets.SFTP_USER }} pass: ${{ secrets.SFTP_PASS }} remoteDir: '/demo-www/wp-content/themes/my-theme' options: '--verbose'

แค่นั้นแหละ! ขั้นตอนการทำงานของคุณสามารถใช้ธีม WordPress ของคุณได้โดยอัตโนมัติ

สร้างและปรับใช้ธีม WordPress ของคุณ

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

ตามตัวอย่างการตั้งค่า เราจะใช้ที่เก็บ GitHub ที่มีสองสาขา:

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

ได้เวลาแนะนำงานบิลด์และเปลี่ยนชื่อเวิร์กโฟลว์ของเราเป็น build build-deploy เนื่องจากจะต้องรับผิดชอบในการสร้างและปรับใช้โค้ดของเรา

 name: build-deploy on: push: branches: - main paths-ignore: - 'bin/**' - 'README.md' jobs: build: runs-on: ubuntu-latest steps: [...] deploy: [...]

ตรวจสอบที่เก็บ Git ของคุณ

งานแต่ละงานทำงานในอินสแตนซ์ใหม่ของอิมเมจนักวิ่ง ดังนั้นคุณต้องตรวจสอบที่เก็บ GitHub ของคุณอีกครั้งในงาน build

 build: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3

คุณไม่จำเป็นต้องดึงข้อมูลประวัติ Git ทั้งหมดในงานบิลด์ คุณจึงใช้ค่าเริ่มต้นสำหรับอินพุตของการดำเนินการได้

การติดตั้งการพึ่งพา

บางธีมใช้แพ็คเกจและไลบรารีของบุคคลที่สาม หากธีมของคุณต้องการแพ็คเกจ PHP และ/หรือ JavaScript คุณอาจต้องการใช้ตัวจัดการแพ็คเกจ เช่น Composer, npm หรือ yarn

สำหรับตัวอย่างนี้ เราจะถือว่าคุณต้องติดตั้งทั้งการขึ้นต่อกันของ Composer และ Node.js โชคดีสำหรับเราที่มีการกระทำที่พร้อมใช้งานสำหรับสิ่งนั้น

 steps: - name: Checkout uses: actions/checkout@v3 - name: Install Composer dependencies uses: php-actions/composer@v6 - name: Install Node.js LTS uses: actions/setup-node@v3 with: node-version: 'lts/*' cache: 'yarn' - name: Install Node.js dependencies run: yarn install

การดำเนินการของ นักแต่งเพลง จะเรียกใช้การ composer install ตามค่าเริ่มต้น ดังนั้นคุณจึงไม่ต้องกำหนดค่าพารามิเตอร์อินพุตใดๆ

สำหรับการดำเนินการ ติดตั้งโหนด เราตั้งค่าที่กำหนดเองสำหรับอินพุต node-version และ cache เพื่อระบุว่าเราต้องการ:

• รับ Node.js เวอร์ชันการสนับสนุนระยะยาว (หรือ LTS)
• แคชการอ้างอิงใด ๆ ที่ดึงผ่านตัวจัดการแพ็คเกจเส้นด้าย

จากนั้น ขั้นตอนต่อไปจะ เรียกใช้การ yarn install เพื่อติดตั้งการพึ่งพา Node.js โปรดจำไว้ว่าขั้นตอนสามารถเรียกใช้สคริปต์หรือ GitHub Action ได้

โปรดทราบว่าการ แคช สามารถเพิ่มความเร็วเวิร์กโฟลว์ของคุณได้อย่างมาก การดาวน์โหลดการอ้างอิงทุกครั้งที่เวิร์กโฟลว์ของคุณทำงานจะทำให้รันไทม์นานขึ้น คุณสามารถแคชการอ้างอิงสำหรับงานโดยใช้การดำเนินการ แคช (ซึ่งเป็นสิ่งที่การดำเนินการ setup-node ทำภายใต้ประทุนเช่นกัน) เร่งเวลาที่ใช้ในการสร้างไฟล์ใหม่

เรียกใช้กระบวนการสร้างของคุณ

เราจะถือว่าคุณต้องดำเนินการตามกระบวนการ "สร้าง" อีกครั้ง คุณอาจต้องเรียกใช้ตัวประมวลผลล่วงหน้าเพื่อคอมไพล์สไตล์ชีตของคุณ แปลงไฟล์สคริปต์ ES6+ ของคุณ ฯลฯ ซึ่งโดยทั่วไปหมายความว่าคุณได้กำหนดสคริปต์สำหรับ build ในของคุณ ไฟล์ package.json

ดังนั้น คุณจะต้องมีขั้นตอนอื่นเพื่อเรียกใช้กระบวนการสร้างนั้น

 - name: Build theme run: yarn run build

หากคุณต้องการเรียกใช้สคริปต์อื่นสำหรับสาขา main และการ preview (เช่น build สำหรับสาขา main และ staging สำหรับการ preview ) คุณสามารถทำได้ดังนี้:

 - name: Build theme run: | if [[ "${{ github.base_ref }}" == "main" || "${{ github.ref }}" == "refs/heads/main" ]]; then yarn run build else yarn run staging fi

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

สิ่งประดิษฐ์

อาร์ติแฟกต์ทำให้คุณสามารถคงข้อมูลไว้ได้หลังจากงานเสร็จสิ้น คุณจึงสามารถแชร์ข้อมูลระหว่างงานในเวิร์กโฟลว์ได้

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

 - name: Upload artifact uses: actions/upload-artifact@v3 with: name: my-theme-build path: | dist/ vendor/ retention-days: 1

ขึ้นอยู่กับขนาดของพื้นที่เก็บข้อมูลและความถี่ที่คุณพุช คุณอาจต้องการดูขีดจำกัดการใช้งาน การเรียกเก็บเงิน และการดูแลระบบของ GitHub

ในขณะที่เขียน ตามค่าเริ่มต้น GitHub จะจัดเก็บบันทึกการสร้างและสิ่งประดิษฐ์เป็นเวลา 90 วัน และให้พื้นที่เก็บข้อมูล 500 MB ในแผน "GitHub ฟรี"

รันงานตามลำดับ

เวิร์กโฟลว์ประกอบด้วยงานตั้งแต่หนึ่งงานขึ้นไป ซึ่งทำงานพร้อมกันโดยค่าเริ่มต้น ในกรณีของเรา เราต้องสร้างธีมของเราก่อนจึงจะปรับใช้ได้ ในการเรียกใช้งานบิลด์และ deploy ตามลำดับ คุณต้องกำหนดการอ้างอิงโดยใช้คีย์เวิร์ด jobs.<job_id>.needs build

 deploy: runs-on: ubuntu-latest needs: build

ในตัวอย่างด้านล่าง เราระบุว่างาน build ด์ต้องเสร็จสมบูรณ์ก่อนจึงจะสามารถเรียกใช้งานการ deploy ใช้

 name: build-deploy on: [...] jobs: build: runs-on: ubuntu-latest steps: [...] deploy: runs-on: ubuntu-latest needs: build steps: [...]

กำลังดาวน์โหลดสิ่งประดิษฐ์

ก่อนที่คุณจะสามารถอัปโหลดข้อมูลใด ๆ ที่สร้างขึ้นในระหว่างขั้นตอนการสร้าง คุณต้องดาวน์โหลดข้อมูลเหล่านั้น มาดูการ deploy งานอีกครั้งและแนะนำขั้นตอนเพิ่มเติม

 - name: Download artifact uses: actions/download-artifact@v3 with: name: my-theme-build path: .

คุณสามารถใช้การดำเนิน การ ดาวน์โหลด -Arti คล้ายกับการ อัปโหลดสิ่งประดิษฐ์ ตรวจสอบให้แน่ใจว่าคุณระบุชื่อเดียวกัน - my-theme-build ในกรณีนี้ - สำหรับทั้งสองการกระทำ

วางมันทั้งหมดเข้าด้วยกัน

 name: build-deploy on: push: branches: - main paths-ignore: - 'bin/**' - 'README.md' jobs: build: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 - name: Install Composer dependencies uses: php-actions/composer@v6 - name: Install Node.js LTS uses: actions/setup-node@v3 with: node-version: 'lts/*' cache: 'yarn' - name: Install Node.js dependencies run: yarn install - name: Build theme run: | if [[ "${{ github.base_ref }}" == "main" || "${{ github.ref }}" == "refs/heads/main" ]]; then yarn run build else yarn run staging fi - name: Upload artifact uses: actions/upload-artifact@v3 with: name: my-theme-build path: | dist/ vendor/ retention-days: 1 deploy: runs-on: ubuntu-latest needs: build steps: - name: Checkout uses: actions/checkout@v3 with: fetch-depth: 0 - name: Download artifact uses: actions/download-artifact@v3 with: name: my-theme-build path: . - name: Deploy via SFTP uses: pressidium/lftp-mirror-action@v1 with: host: ${{ secrets.SFTP_HOST }} port: ${{ secrets.SFTP_PORT }} user: ${{ secrets.SFTP_USER }} pass: ${{ secrets.SFTP_PASS }} remoteDir: '/demo-www/wp-content/themes/my-theme' options: '--verbose'

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

ปรับใช้ธีมของคุณกับสภาพแวดล้อมที่หลากหลาย

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

ดังนั้นเรามาสร้างความลับที่แตกต่างกันสำหรับชื่อผู้ใช้/รหัสผ่านของผู้ใช้แต่ละคน ซึ่งหมายความว่ารายการลับที่เข้ารหัสที่อัปเดตของเราควรมีลักษณะดังนี้:

• SFTP_HOST
• SFTP_PORT
• SFTP_PROD_USER
• SFTP_PROD_PASS
• SFTP_STAG_USER
• SFTP_STAG_PASS

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

การตั้งค่าตัวแปรสภาพแวดล้อม

ตัวแปรสภาพแวดล้อม คือตัวแปรที่ประกอบด้วยคู่ของชื่อ/ค่า และเป็นส่วนหนึ่งของสภาพแวดล้อมที่กระบวนการทำงาน

ในเวิร์กโฟลว์ GitHub Actions คุณสามารถใช้คีย์เวิร์ด env เพื่อตั้งค่าตัวแปรสภาพแวดล้อมที่กำหนดเองซึ่งมีขอบเขตสำหรับ:

• เวิร์กโฟลว์ทั้งหมด โดยใช้ env ที่ระดับบนสุดของเวิร์กโฟลว์
• งานภายในเวิร์กโฟลว์ โดยใช้ env ที่ระดับของงานนั้น
• ขั้นตอนเฉพาะภายในงาน โดยใช้ env ที่ระดับของขั้นตอนนั้น

คุณยังสามารถผนวกตัวแปรสภาพแวดล้อมเข้ากับ $GITHUB_ENV ซึ่งทำให้ตัวแปรนั้นพร้อมใช้งานสำหรับขั้นตอนต่อๆ ไปในงานเวิร์กโฟลว์

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

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

 - name: Set environment variables (main) if: github.ref == 'refs/heads/main' run: | echo "SFTP_USER=${{ secrets.SFTP_PROD_USER }}" >> $GITHUB_ENV echo "SFTP_PASS=${{ secrets.SFTP_PROD_PASS }}" >> $GITHUB_ENV echo "DEPLOY_PATH=/demo-www/wp-content/themes/my-theme" >> $GITHUB_ENV - name: Set environment variables (preview) if: github.ref == 'refs/heads/preview' run: | echo "SFTP_USER=${{ secrets.SFTP_STAG_USER }}" >> $GITHUB_ENV echo "SFTP_PASS=${{ secrets.SFTP_STAG_PASS }}" >> $GITHUB_ENV echo "DEPLOY_PATH=/demo-dev-www/wp-content/themes/my-theme" >> $GITHUB_ENV

เราใช้คำหลัก if เพื่อจำกัดแต่ละขั้นตอนไว้เฉพาะสาขา ด้วยวิธีนี้ ตั้งค่าตัวแปรสภาพแวดล้อม (หลัก) จะทำงานก็ต่อเมื่อการเปลี่ยนแปลงถูกพุชไปยังสาขา main เท่านั้น

$DEPLOY_PATH อาจแตกต่างกันไปในแต่ละสภาพแวดล้อม

ตัวอย่างเช่น บน Pressidium:

• เส้นทางสำหรับสภาพแวดล้อมการผลิตเป็นไปตามรูปแบบ /<WEBSITE_NAME>-www/
• เส้นทางสำหรับสภาพแวดล้อมการจัดเตรียมเป็นไปตามรูปแบบ /<WEBSITE_NAME>-dev-www/

การตั้งค่าเอาต์พุต

เราต้องการใช้ตัวแปรสภาพแวดล้อมที่เราเพิ่งตั้งค่าเป็นอินพุตให้กับ GitHub Action ที่จะถ่ายโอนไฟล์ผ่าน SFTP

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

 - name: Set outputs # Workaround to reference environment variables as inputs # using step outputs, since we can't pass environment # variables as inputs at the moment. id: sftp_details run: | echo "user=${SFTP_USER}" >> $GITHUB_OUTPUT echo "pass=${SFTP_PASS}" >> $GITHUB_OUTPUT echo "deploy_path=${DEPLOY_PATH}" >> $GITHUB_OUTPUT

ขณะนี้ คุณมีเอาต์พุต user , pass และ deploy_path สำหรับขั้นตอน sftp_details ซึ่งคุณสามารถใช้อ้างอิงค่าเหล่านี้เป็นอินพุตของขั้นตอนถัดไปได้

การอัปโหลดไฟล์ไปยังสภาพแวดล้อมต่างๆ

การอัปโหลดไฟล์ผ่าน SFTP ค่อนข้างเหมือนเดิม แต่แทนที่จะอ้างอิงบริบท secrets และฮาร์ดโค้ด remoteDir คุณจะใช้ผลลัพธ์ของขั้นตอนก่อนหน้า

 - name: Deploy via SFTP uses: pressidium/lftp-mirror-action@v1 with: host: ${{ secrets.SFTP_HOST }} port: ${{ secrets.SFTP_PORT }} user: ${{ steps.sftp_details.outputs.user }} pass: ${{ steps.sftp_details.outputs.pass }} remoteDir: ${{ steps.sftp_details.outputs.deploy_path }} options: '--verbose'

ใช้ ${{ steps.<step_id>.outputs.<output_name> }} เพื่อเข้าถึงผลลัพธ์ของขั้นตอน ตัวอย่างเช่น ${{ steps.sftp_details.outputs.user }} เพื่อเข้าถึงเอาต์พุต user ของขั้นตอน sftp_details

ว้า ในที่สุด! เวิร์กโฟลว์ของคุณสามารถสร้าง และ ปรับใช้ธีม WordPress ของคุณกับทั้งสภาพแวดล้อมการผลิต และ การแสดงละครของคุณ

รวมเวิร์กโฟลว์ทั้งหมดเข้าด้วยกัน

 name: build-deploy on: push: branches: # Pushing to any of the following # branches will trigger our workflow - main - preview paths-ignore: # When all the path names match patterns in `paths-ignore` # the workflow will not run. We don't want to do anything # if we have changed *only* (some of) these files - 'bin/**' - 'README.md' jobs: build: runs-on: ubuntu-latest steps: - name: Checkout # Checkout our repository under `${GITHUB_WORKSPACE}`, # so our workflow can access it uses: actions/checkout@v3 - name: Install Composer dependencies # This will run `composer install` # since that's its default command uses: php-actions/composer@v6 - name: Install Node.js LTS # We use the LTS version of Node.js # and cache packages installed via yarn uses: actions/setup-node@v3 with: node-version: 'lts/*' cache: 'yarn' - name: Install Node.js dependencies run: yarn install - name: Build theme # Run the `build` script for production, # and the `staging` script for staging run: | if [[ "${{ github.base_ref }}" == "main" || "${{ github.ref }}" == "refs/heads/main" ]]; then yarn run build else yarn run staging fi - name: Upload artifact # Persist data produced during the build steps # with a retention period of 1 day uses: actions/upload-artifact@v3 with: name: my-theme-build path: | dist/ vendor/ retention-days: 1 deploy: runs-on: ubuntu-latest needs: build steps: - name: Checkout uses: actions/checkout@v3 with: # Fetch the entire Git history fetch-depth: 0 - name: Download artifact uses: actions/download-artifact@v3 with: name: my-theme-build path: . - name: Set environment variables (main) if: github.ref == 'refs/heads/main' run: | echo "SFTP_USER=${{ secrets.SFTP_PROD_USER }}" >> $GITHUB_ENV echo "SFTP_PASS=${{ secrets.SFTP_PROD_PASS }}" >> $GITHUB_ENV echo "DEPLOY_PATH=/demo-www/wp-content/themes/my-theme" >> $GITHUB_ENV - name: Set environment variables (preview) if: github.ref == 'refs/heads/preview' run: | echo "SFTP_USER=${{ secrets.SFTP_STAG_USER }}" >> $GITHUB_ENV echo "SFTP_PASS=${{ secrets.SFTP_STAG_PASS }}" >> $GITHUB_ENV echo "DEPLOY_PATH=/demo-dev-www/wp-content/themes/my-theme" >> $GITHUB_ENV - name: Set outputs # Workaround to reference environment variables as inputs # using step outputs, since we can't pass environment # variables as inputs at the moment. id: sftp_details run: | echo "user=${SFTP_USER}" >> $GITHUB_OUTPUT echo "pass=${SFTP_PASS}" >> $GITHUB_OUTPUT echo "deploy_path=${DEPLOY_PATH}" >> $GITHUB_OUTPUT - name: Deploy via SFTP uses: pressidium/lftp-mirror-action@v1 with: host: ${{ secrets.SFTP_HOST }} port: ${{ secrets.SFTP_PORT }} user: ${{ steps.sftp_details.outputs.user }} pass: ${{ steps.sftp_details.outputs.pass }} remoteDir: ${{ steps.sftp_details.outputs.deploy_path }} options: '--verbose'

คุณยังสามารถค้นหาตัวอย่างธีม WordPress และเวิร์กโฟลว์ GitHub Actions ได้ในที่เก็บ GitHub นี้

บทสรุป

คุณมีมัน! GitHub Actions เป็นเครื่องมืออันทรงพลังที่ทำให้การสร้างและการปรับใช้ธีมและปลั๊กอิน WordPress ของคุณเป็นแบบอัตโนมัติเป็นเรื่องง่าย

เราแทบจะไม่มีรอยขีดข่วนของสิ่งที่คุณสามารถทำได้ด้วย GitHub Actions ขั้นตอนต่อไปของคุณอาจเป็นการดำเนินการทดสอบใดๆ ที่คุณอาจมี การเปิดปัญหาหรือการแจ้งเตือนบน Slack โดยอัตโนมัติเมื่อการปรับใช้เสร็จสิ้น และรายการจะดำเนินต่อไป

ดูที่ GitHub Marketplace ซึ่ง ณ เวลาที่เขียน คุณจะพบการกระทำมากกว่า 15,000 รายการที่จะใช้ในเวิร์กโฟลว์ GitHub Actions ของคุณ

ดังนั้นสิ่งที่คุณรอ?

• ดูเวิร์กโฟลว์ของที่เก็บนี้บน GitHub
• สร้างไฟล์ YAML ใหม่ภายใต้ .github/workflows/ ในที่เก็บ Git ของคุณ
• เพลิดเพลินกับการสร้างและการปรับใช้อัตโนมัติ

มีความสุขในการปรับใช้!