วิธีสร้างไปป์ไลน์การปรับใช้เบื้องต้นที่มีประสิทธิภาพ

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

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

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

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

• GitLab เพื่อโฮสต์รหัส
  • เหตุผล: ลูกค้าของฉันชอบโค้ดที่เก็บไว้เป็นความลับ และ Free Tier ของ GitLab นั้นยอดเยี่ยมมาก นอกจากนี้ CI ฟรีแบบรวมก็ยอดเยี่ยมเช่นกัน ขอบคุณ GitLab!
  • ทางเลือกอื่น: GitHub, BitBucket, AWS CodeCommit และอีกมากมาย
• GitLab CI เพื่อสร้าง ทดสอบ และปรับใช้โค้ดของเรา
  • เหตุผล: มันรวมเข้ากับ GitLab และฟรี!
  • ทางเลือกอื่น: TravisCI, Codeship, CircleCI, DIY with Fabric8 และอื่นๆ อีกมากมาย
• Heroku เพื่อโฮสต์แอพของเรา
  • เหตุผล: ใช้งานได้ทันทีและเป็นแพลตฟอร์มที่สมบูรณ์แบบสำหรับการเริ่มต้น คุณเปลี่ยนแปลงสิ่งนี้ได้ในอนาคต แต่ไม่จำเป็นต้องเรียกใช้แอปใหม่ทุกแอปในคลัสเตอร์ Kubernetes ที่สร้างขึ้นโดยเฉพาะ แม้แต่ Coinbase ก็เริ่มต้นจาก Heroku
  • ทางเลือกอื่น: AWS, DigitalOcean, Vultr, DIY with Kubernetes และอื่นๆ อีกมากมาย

โรงเรียนเก่า: สร้างแอปพื้นฐานและปรับใช้กับ Heroku

ขั้นแรก มาสร้างแอปพลิเคชันทั่วไปขึ้นมาใหม่สำหรับผู้ที่ไม่ได้ใช้ไปป์ไลน์ CI/CD แฟนซี และเพียงต้องการปรับใช้แอปพลิเคชันของตน

ไม่สำคัญว่าคุณกำลังสร้างแอปประเภทใด แต่คุณจะต้องใช้ Yarn หรือ npm สำหรับตัวอย่างของฉัน ฉันกำลังสร้างแอปพลิเคชัน Ruby on Rails เพราะมันมาพร้อมกับการโยกย้ายและ CLI และฉันได้เขียนการกำหนดค่าไว้แล้ว คุณสามารถใช้เฟรมเวิร์กหรือภาษาใดก็ได้ที่คุณต้องการ แต่คุณต้องใช้ Yarn เพื่อทำเวอร์ชันที่ฉันทำในภายหลัง ฉันกำลังสร้างแอป CRUD อย่างง่ายโดยใช้คำสั่งเพียงไม่กี่คำสั่งและไม่มีการตรวจสอบสิทธิ์

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

และมาปรับใช้กับ Heroku โดยกดรหัสของเราและเรียกใช้การโยกย้าย

 $ heroku create toptal-pipeline Creating ⬢ toptal-pipeline... done https://toptal-pipeline.herokuapp.com/ | https://git.heroku.com/toptal-pipeline.git $ git push heroku master Counting objects: 132, done. ... To https://git.heroku.com/toptal-pipeline.git * [new branch] master -> master $ heroku run rails db:migrate Running rails db:migrate on ⬢ toptal-pipeline... up, run.9653 (Free) ...

สุดท้ายมาทดสอบกันในการผลิต

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

ข้อดี

• รวดเร็วในการตั้งค่า
• การปรับใช้เป็นเรื่องง่าย

ข้อเสีย

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

ไปป์ไลน์การปรับใช้เบื้องต้นที่สมบูรณ์แบบ

วันนี้ฉันจะลองทำบางอย่างที่ต่างไปจากเดิม: มาพูดคุยแบบสมมติกัน ฉันจะให้เสียงกับ "คุณ" และเราจะพูดถึงวิธีที่เราสามารถปรับปรุงกระแสปัจจุบันนี้ พูดอะไรสักอย่างสิ

พูดว่าอะไรนะ? รอ—ฉันคุยได้ไหม

ใช่ นั่นคือสิ่งที่ฉันหมายถึงการให้เสียงคุณ คุณเป็นอย่างไรบ้าง?

ฉันสบายดี. มันรู้สึกแปลกๆ

เข้าใจค่ะ แต่เดี๋ยวค่อยว่ากัน ทีนี้มาพูดถึงไปป์ไลน์ของเรากัน อะไรคือส่วนที่น่ารำคาญที่สุดในการรันการปรับใช้?

โอ้ง่าย ระยะเวลาที่ฉันเสียไป คุณเคยพยายามผลักดันให้ Heroku หรือไม่?

ใช่ การดูการพึ่งพาการดาวน์โหลดและแอปพลิเคชันที่สร้างขึ้นโดยเป็นส่วนหนึ่งของการ git push นั้นแย่มาก!

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

ตกลงคุณสามารถแก้ปัญหาหลังนั้นได้จริงโดยการผูกสองคำสั่งด้วย && เช่น git push heroku master && heroku run rails db:migrate หรือเพียงแค่สร้าง bash script และใส่ลงในโค้ดของคุณ แต่ก็ยังเป็นคำตอบที่ดี เวลาและการทำซ้ำเป็นความเจ็บปวดอย่างแท้จริง

ใช่มันแย่มาก

จะเกิดอะไรขึ้นถ้าฉันบอกคุณว่าคุณสามารถแก้ไขบิตนั้นได้ทันทีด้วยไปป์ไลน์ CI/CD

อะไรตอนนี้? นั่นคืออะไร?

CI/CD ย่อมาจากการผนวกรวมอย่างต่อเนื่อง (CI) และการส่งมอบ/การปรับใช้อย่างต่อเนื่อง (CD) มันค่อนข้างยากสำหรับฉันที่จะเข้าใจอย่างถ่องแท้ว่าตอนที่ฉันเริ่มต้นคืออะไร เพราะทุกคนใช้คำศัพท์ที่คลุมเครือ เช่น "การควบรวมกิจการของการพัฒนาและการดำเนินงาน" แต่พูดง่ายๆ ก็คือ

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

โอ้ ฉันเข้าใจแล้ว มันเกี่ยวกับการทำให้แอพของฉันปรับใช้กับโลกได้อย่างน่าอัศจรรย์!

บทความที่ฉันโปรดปรานที่อธิบาย CI/CD คือโดย Atlassian ที่นี่ สิ่งนี้ควรล้างคำถามที่คุณมี อย่างไรก็ตามกลับไปที่ปัญหา

ใช่กลับไปที่นั้น ฉันจะหลีกเลี่ยงการปรับใช้ด้วยตนเองได้อย่างไร

การตั้งค่าไปป์ไลน์ CI/CD เพื่อปรับใช้บน Push to master

ถ้าฉันบอกคุณว่าคุณสามารถแก้ไขได้ทันทีด้วย CI/CD คุณสามารถกดไปที่รีโมท GitLab ของคุณ ( origin ) และคอมพิวเตอร์จะถูกสร้างขึ้นให้ตรงขึ้นเพียงแค่กดรหัสของคุณไปที่ Heroku

ไม่มีทาง!

ใช่วิธี! กลับไปที่โค้ดกันอีกครั้ง

สร้าง .gitlab-ci.yml ที่มีเนื้อหาต่อไปนี้ สลับ toptal-pipeline เป็นชื่อแอป Heroku ของคุณ:

 image: ruby:2.4 before_script: - > : "${HEROKU_EMAIL:?Please set HEROKU_EMAIL in your CI/CD config vars}" - > : "${HEROKU_AUTH_TOKEN:?Please set HEROKU_AUTH_TOKEN in your CI/CD config vars}" - curl https://cli-assets.heroku.com/install-standalone.sh | sh - | cat >~/.netrc <<EOF machine api.heroku.com login $HEROKU_EMAIL password $HEROKU_AUTH_TOKEN machine git.heroku.com login $HEROKU_EMAIL password $HEROKU_AUTH_TOKEN EOF - chmod 600 ~/.netrc - git config --global user.email "[email protected]" - git config --global user.name "CI/CD" variables: APPNAME_PRODUCTION: toptal-pipeline deploy_to_production: stage: deploy environment: name: production url: https://$APPNAME_PRODUCTION.herokuapp.com/ script: - git remote add heroku https://git.heroku.com/$APPNAME_PRODUCTION.git - git push heroku master - heroku pg:backups:capture --app $APPNAME_PRODUCTION - heroku run rails db:migrate --app $APPNAME_PRODUCTION only: - master

ผลักดันสิ่งนี้ และดูว่ามันล้มเหลวในหน้าไปป์ไลน์ของโครงการของคุณ นั่นเป็นเพราะมันไม่มีคีย์การตรวจสอบสิทธิ์สำหรับบัญชี Heroku ของคุณ การแก้ไขที่ค่อนข้างตรงไปตรงมาแม้ว่า ก่อนอื่น คุณจะต้องมี คีย์ Heroku API ของคุณ รับจากหน้าจัดการบัญชี แล้วเพิ่ม ตัวแปรลับ ต่อไปนี้ในการตั้งค่า CI/CD ของ GitLab repo ของคุณ:

• HEROKU_EMAIL : ที่อยู่อีเมลที่คุณใช้เพื่อลงชื่อเข้าใช้ Heroku
• HEROKU_AUTH_KEY : กุญแจที่ได้รับจาก Heroku

สิ่งนี้จะส่งผลให้ GitLab ใช้งานได้กับ Heroku ทุกครั้งที่มีการกด เกิดอะไรขึ้น:

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

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

การสร้างสภาพแวดล้อมการแสดงละคร

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

ฉันใช้ PostgreSQL ในการพัฒนาอย่างเคร่งครัด ฉันไม่เคยใช้เอ็นจิ้นฐานข้อมูลแบบนั้นไม่ตรงกัน และฉันตรวจสอบสแต็กของฉันอย่างขยันขันแข็งเพื่อหาความไม่ลงรอยกันที่อาจเกิดขึ้น

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

Errrr— ใช่ไม่ คุณพาฉันไปที่นั่น คนอื่นจะยุ่ง ประเด็นของคุณคืออะไร?

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

นี้ทำให้รู้สึก! แล้วฉันจะทำสิ่งนี้ได้อย่างไร?

นี่คือสิ่งที่น่าสนใจ ฉันชอบปรับใช้ master โดยตรงกับการแสดงละคร

เดี๋ยวนะ นั่นไม่ใช่ที่ที่เรากำลังปรับใช้การผลิตอยู่ใช่หรือไม่?

ใช่ แต่ตอนนี้เราจะปรับใช้กับการแสดงละครแทน

แต่ถ้า master ปรับใช้กับการแสดงละคร เราจะปรับใช้กับการผลิตได้อย่างไร

โดยใช้สิ่งที่คุณควรทำเมื่อหลายปีก่อน: กำหนดเวอร์ชันโค้ดของเราและกดแท็ก Git

แท็ก Git? ใครใช้ Git tag บ้าง! นี้เริ่มฟังดูเหมือนเป็นงานมาก

แน่นอน แต่โชคดีที่ฉันได้ทำทุกอย่างแล้ว และคุณสามารถทิ้งรหัสของฉันและมันจะได้ผล

ขั้นแรก เพิ่มบล็อกเกี่ยวกับการปรับใช้การแสดงละครในไฟล์ .gitlab-ci.yml ของคุณ ฉันได้สร้างแอป Heroku ใหม่ชื่อ toptal-pipeline-staging :

 … variables: APPNAME_PRODUCTION: toptal-pipeline APPNAME_STAGING: toptal-pipeline-staging deploy_to_staging: stage: deploy environment: name: staging url: https://$APPNAME_STAGING.herokuapp.com/ script: - git remote add heroku https://git.heroku.com/$APPNAME_STAGING.git - git push heroku master - heroku pg:backups:capture --app $APPNAME_PRODUCTION - heroku pg:backups:restore `heroku pg:backups:url --app $APPNAME_PRODUCTION` --app $APPNAME_STAGING --confirm $APPNAME_STAGING - heroku run rails db:migrate --app $APPNAME_STAGING only: - master - tags ...

จากนั้นเปลี่ยนบรรทัดสุดท้ายของบล็อกการผลิตของคุณให้ทำงานบนแท็ก Git ที่มีเวอร์ชันความหมายแทนสาขาหลัก:

 deploy_to_production: ... only: - /^v(?'MAJOR'(?:0|(?:[1-9]\d*)))\.(?'MINOR'(?:0|(?:[1-9]\d*)))\.(?'PATCH'(?:0|(?:[1-9]\d*)))(?:-(?'prerelease'[0-9A-Za-z-]+(\.[0-9A-Za-z-]+)*))?(?:\+(?'build'[0-9A-Za-z-]+(\.[0-9A-Za-z-]+)*))?$/ # semver pattern above is adapted from https://github.com/semver/semver.org/issues/59#issuecomment-57884619

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

มาสรุปสิ่งที่เกิดขึ้นตอนนี้:

• เมื่อกดไปที่มาสเตอร์หรือกดคอมมิชชันที่ติดแท็ก
  • Heroku CLI ได้รับการติดตั้งและรับรองความถูกต้องในคอนเทนเนอร์
  • รหัสของคุณถูกผลักไปที่ Heroku
  • การสำรองข้อมูลของการผลิตฐานข้อมูลของคุณจะถูกบันทึกไว้ใน Heroku
  • ข้อมูลสำรองถูกดัมพ์ในสภาพแวดล้อมการจัดเตรียมของคุณ
  • การโยกย้ายถูกรันบนฐานข้อมูล staging
• เมื่อผลักเวอร์ชันความหมายที่ติดแท็ก commit
  • Heroku CLI ได้รับการติดตั้งและรับรองความถูกต้องในคอนเทนเนอร์
  • รหัสของคุณถูกผลักไปที่ Heroku
  • การสำรองข้อมูลของการผลิตฐานข้อมูลของคุณจะถูกบันทึกไว้ใน Heroku
  • การย้ายข้อมูลจะดำเนินการบนฐานข้อมูลที่ใช้งานจริง

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

ทดสอบทุกการกด

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

ฉันชอบที่จะมีสิ่งนี้อยู่ในขั้นตอนของฉัน มันทำให้การรีวิวโค้ดของฉันสนุก หากคำขอรวมผ่านการตรวจสอบรหัสทั้งหมดของฉัน ก็สมควรได้รับการตรวจสอบ

เพิ่มบล็อก test :

 test: stage: test variables: POSTGRES_USER: test POSTGRES_PASSSWORD: test-password POSTGRES_DB: test DATABASE_URL: postgres://${POSTGRES_USER}:${POSTGRES_PASSSWORD}@postgres/${POSTGRES_DB} RAILS_ENV: test services: - postgres:alpine before_script: - curl -sL https://deb.nodesource.com/setup_8.x | bash - apt-get update -qq && apt-get install -yqq nodejs libpq-dev - curl -o- -L https://yarnpkg.com/install.sh | bash - source ~/.bashrc - yarn - gem install bundler --no-ri --no-rdoc - bundle install -j $(nproc) --path vendor - bundle exec rake db:setup RAILS_ENV=test script: - bundle exec rake spec - bundle exec rubocop

มาสรุปสิ่งที่เกิดขึ้นตอนนี้:

• ทุกครั้งที่กดหรือรวมคำขอ
  • Ruby และ Node ถูกตั้งค่าในคอนเทนเนอร์
  • มีการติดตั้งการพึ่งพา
  • แอปได้รับการทดสอบแล้ว
• เมื่อกดไปที่มาสเตอร์หรือกดคอมมิตที่ติดแท็ก และเฉพาะเมื่อการทดสอบทั้งหมดผ่าน
  • Heroku CLI ได้รับการติดตั้งและรับรองความถูกต้องในคอนเทนเนอร์
  • รหัสของคุณถูกผลักไปที่ Heroku
  • การสำรองข้อมูลของการผลิตฐานข้อมูลของคุณจะถูกบันทึกไว้ใน Heroku
  • ข้อมูลสำรองถูกดัมพ์ในสภาพแวดล้อมการจัดเตรียมของคุณ
  • การโยกย้ายถูกรันบนฐานข้อมูล staging
• เมื่อกดส่งเวอร์ชันความหมายที่ติดแท็ก commit และเฉพาะในกรณีที่การทดสอบทั้งหมดผ่าน
  • Heroku CLI ได้รับการติดตั้งและรับรองความถูกต้องในคอนเทนเนอร์
  • รหัสของคุณถูกผลักไปที่ Heroku
  • การสำรองข้อมูลของการผลิตฐานข้อมูลของคุณจะถูกบันทึกไว้ใน Heroku
  • การย้ายข้อมูลจะดำเนินการบนฐานข้อมูลที่ใช้งานจริง

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

การกำหนดเวอร์ชันความหมายอัตโนมัติ

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

โอเคเพื่อนหยุด! พอแล้ว. ตอนนี้คุณแค่กำลังพัฒนามันมากเกินไป มันได้ผล มันยอดเยี่ยม อย่าทำลายความดีด้วยการไปให้ถึงจุดสูงสุด

โอเค ฉันมีเหตุผลที่ดีที่จะทำในสิ่งที่ฉันกำลังจะทำ

อธิษฐานขอความกระจ่างแก่ฉัน

ฉันเคยเป็นเหมือนคุณ ฉันมีความสุขกับการตั้งค่านี้ แต่แล้วฉันก็ทำผิดพลาด git tag แสดงรายการแท็กตามลำดับตัวอักษร v0.0.11 อยู่เหนือ v0.0.2 ครั้งหนึ่งฉันติดแท็กรุ่นโดยไม่ได้ตั้งใจและทำต่ออีกประมาณครึ่งโหลจนกระทั่งเห็นข้อผิดพลาด นั่นคือตอนที่ฉันตัดสินใจทำให้สิ่งนี้เป็นอัตโนมัติด้วย

มาอีกแล้วววว

โอเค โชคดีที่เรามีพลังของ npm อยู่ในมือ ดังนั้นฉันจึงพบแพ็คเกจที่เหมาะสม: รัน yarn add --dev standard-version และเพิ่มสิ่งต่อไปนี้ในไฟล์ package.json ของคุณ:

 "scripts": { "release": "standard-version", "major": "yarn release --release-as major", "minor": "yarn release --release-as minor", "patch": "yarn release --release-as patch" },

ตอนนี้ คุณต้องทำสิ่งสุดท้าย กำหนดค่า Git ให้กดแท็กโดยค่าเริ่มต้น ในขณะนี้ คุณต้องเรียกใช้ git push --tags เพื่อดันแท็กขึ้น แต่การทำเช่นนั้นโดยอัตโนมัติเมื่อทำการ git push ปกตินั้นง่ายพอๆ กับการรัน git config --global push.followTags true

ในการใช้ไปป์ไลน์ใหม่ของคุณ เมื่อใดก็ตามที่คุณต้องการสร้างการเปิดตัว:

• yarn patch สำหรับแพทช์ปล่อย
• yarn minor สำหรับรุ่นย่อย
• yarn major สำหรับรุ่นใหญ่

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

เมื่อคุณทำไปป์ไลน์เสร็จแล้ว มาสรุปวิธีใช้งานกัน!

• เขียนโค้ด.
• ยอมรับและผลักดันเพื่อทดสอบและปรับใช้กับการแสดงละคร
• ใช้ yarn patch เพื่อติดแท็กการปล่อยแพทช์
• git push เพื่อดันออกสู่การผลิต

สรุปและขั้นตอนเพิ่มเติม

ฉันเพิ่งขีดข่วนพื้นผิวของสิ่งที่เป็นไปได้ด้วยไปป์ไลน์ CI/CD นี่เป็นตัวอย่างที่ค่อนข้างง่าย คุณสามารถทำสิ่งต่างๆ ได้มากขึ้นด้วยการแลกเปลี่ยน Heroku กับ Kubernetes หากคุณตัดสินใจใช้ GitLab CI โปรดอ่านเอกสาร yaml เพราะยังมีอะไรอีกมากมายที่คุณสามารถทำได้โดยการแคชไฟล์ระหว่างการปรับใช้ หรือการบันทึกสิ่งประดิษฐ์!

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

ในที่สุด เมื่อแอปพลิเคชันของคุณเริ่มซับซ้อนและต้องการการพึ่งพาระดับระบบ คุณอาจต้องใช้คอนเทนเนอร์ เมื่อสิ่งนี้เกิดขึ้น โปรดดูคำแนะนำของเรา: เริ่มต้นใช้งาน Docker: Simplifying Devops

แอปตัวอย่างนี้ใช้งานได้จริง และคุณสามารถค้นหาซอร์สโค้ดได้ที่นี่