บทแนะนำการจัดส่งแบบต่อเนื่อง - การสร้างท่อส่งสินค้าแบบต่อเนื่องโดยใช้ Jenkins

บล็อกเกี่ยวกับการจัดส่งแบบต่อเนื่องนี้จะอธิบายแต่ละขั้นตอนที่เกี่ยวข้องเช่น Build, Test และอื่น ๆ ด้วยการใช้ Jenkins

การจัดส่งต่อเนื่อง:

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



  • การจัดส่งแบบต่อเนื่องคืออะไร?
  • ประเภทของการทดสอบซอฟต์แวร์
  • ความแตกต่างระหว่างการรวมการส่งมอบและการปรับใช้อย่างต่อเนื่อง
  • ความต้องการในการจัดส่งแบบต่อเนื่องคืออะไร?
  • ลงมือใช้ Jenkins และ Tomcat

ให้เราเข้าใจอย่างรวดเร็วว่าการจัดส่งแบบต่อเนื่องทำงานอย่างไร

การจัดส่งแบบต่อเนื่องคืออะไร?

เป็นกระบวนการที่คุณสร้างซอฟต์แวร์ในลักษณะที่สามารถเผยแพร่สู่การผลิตได้ตลอดเวลาพิจารณาแผนภาพด้านล่าง:

การจัดส่งแบบต่อเนื่อง - การจัดส่งแบบต่อเนื่อง - Edureka



ให้ฉันอธิบายแผนภาพด้านบน:

  • สร้างสคริปต์อัตโนมัติจะตรวจจับการเปลี่ยนแปลงใน Source Code Management (SCM) เช่น Git
  • เมื่อตรวจพบการเปลี่ยนแปลงซอร์สโค้ดจะถูกปรับใช้กับเซิร์ฟเวอร์บิลด์เฉพาะเพื่อให้แน่ใจว่าบิวด์ไม่ล้มเหลวและคลาสทดสอบและการทดสอบการรวมทั้งหมดทำงานได้ดี
  • จากนั้นสร้างแอ็พพลิเคชันบนเซิร์ฟเวอร์ทดสอบ (เซิร์ฟเวอร์ก่อนการผลิต) สำหรับ User Acceptance Test (UAT)
  • ในที่สุดแอปพลิเคชันจะถูกปรับใช้ด้วยตนเองบนเซิร์ฟเวอร์ที่ใช้งานจริงเพื่อนำออกใช้

ก่อนที่จะดำเนินการต่อจะเป็นการยุติธรรมที่จะอธิบายให้คุณทราบถึงการทดสอบประเภทต่างๆ

ประเภทของการทดสอบซอฟต์แวร์:

การทดสอบโดยทั่วไปมีสองประเภท:



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

การทดสอบ Whitebox:

มีการทดสอบสองประเภทซึ่งอยู่ในหมวดหมู่นี้

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

การทดสอบ Blackbox:

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

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

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

ความแตกต่างระหว่างการรวมการส่งมอบและการปรับใช้อย่างต่อเนื่อง:

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

ในการผสานรวมอย่างต่อเนื่องทุกรหัสคอมมิตจะถูกสร้างและทดสอบ แต่ไม่อยู่ในเงื่อนไขที่จะปล่อย ฉันหมายความว่าแอปพลิเคชันบิลด์ไม่ได้ถูกปรับใช้โดยอัตโนมัติบนเซิร์ฟเวอร์ทดสอบเพื่อตรวจสอบความถูกต้องโดยใช้การทดสอบ Blackbox ประเภทต่างๆเช่น - การทดสอบการยอมรับของผู้ใช้ (UAT)

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

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

ให้ฉันสรุปความแตกต่างโดยใช้ตาราง:

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

พูดง่ายๆคือ Continuous Integration เป็นส่วนหนึ่งของทั้ง Continuous Delivery และ Continuous Deployment และ Continuous Deployment ก็เหมือนกับ Continuous Delivery ยกเว้นว่าการเผยแพร่จะเกิดขึ้นโดยอัตโนมัติ

เรียนรู้วิธีสร้างไปป์ไลน์ CI / CD โดยใช้ Jenkins บนคลาวด์

แต่คำถามคือว่า Continuous Integration เพียงพอหรือไม่

ทำไมเราต้องจัดส่งอย่างต่อเนื่อง

ให้เราเข้าใจสิ่งนี้ด้วยตัวอย่าง

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

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

อะไรคือสาเหตุที่ชัดเจนของความล้มเหลว

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

นักพัฒนาด้านการรับรู้คนหนึ่งใช้แนวทางที่ชาญฉลาด:

จากนั้นนักพัฒนาอาวุโสคนหนึ่งได้ลองใช้แอปพลิเคชันบนเครื่องพัฒนาของเขา มันก็ใช้ไม่ได้เช่นกัน

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

คำชี้แจงปัญหา:

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

ให้ฉันสรุปบทเรียนที่ได้เรียนรู้โดยดูปัญหาข้างต้น:

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

โซลูชัน - ไปป์ไลน์การจัดส่งแบบต่อเนื่อง (การทดสอบการยอมรับอัตโนมัติ):

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

วิธีตั้งค่า java classpath

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

พอมีทฤษฎีแล้วฉันจะแสดงวิธีสร้างไปป์ไลน์การจัดส่งแบบต่อเนื่องโดยใช้เจนกินส์

ท่อส่งสินค้าต่อเนื่องโดยใช้ Jenkins:

ฉันจะใช้ Jenkins ในการสร้าง Continuous Delivery Pipeline ซึ่งจะรวมถึงงานต่อไปนี้:

ขั้นตอนที่เกี่ยวข้องในการสาธิต:

  • ดึงรหัสจาก GitHub
  • รวบรวมซอร์สโค้ด
  • การทดสอบหน่วยและการสร้างรายงานการทดสอบ JUnit
  • แพ็กเกจแอปพลิเคชันลงในไฟล์ WAR และปรับใช้บนเซิร์ฟเวอร์ Tomcat

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

  • เครื่อง CentOS 7
  • เจนกินส์ 2.121.1
  • นักเทียบท่า
  • ทอมแคท 7

ขั้นตอน - 1 รวบรวมซอร์สโค้ด:

เริ่มต้นด้วยการสร้างโครงการ Freestyle ใน Jenkins ก่อน พิจารณาภาพหน้าจอด้านล่าง:

ตั้งชื่อโครงการของคุณและเลือก Freestyle Project:

เมื่อคุณเลื่อนลงคุณจะพบตัวเลือกในการเพิ่มที่เก็บซอร์สโค้ดเลือก git และเพิ่ม URL ที่เก็บในที่เก็บนั้นจะมี pom.xml ที่ดีซึ่งเราจะใช้เพื่อสร้างโครงการของเรา พิจารณาภาพหน้าจอด้านล่าง:

ตอนนี้เราจะเพิ่ม Build Trigger เลือกตัวเลือก SCM แบบสำรวจโดยพื้นฐานแล้วเราจะกำหนดค่า Jenkins เพื่อสำรวจความคิดเห็นในที่เก็บ GitHub ทุก ๆ 5 นาทีสำหรับการเปลี่ยนแปลงในโค้ด พิจารณาภาพหน้าจอด้านล่าง:

ก่อนที่จะดำเนินการต่อขอแนะนำเล็กน้อยเกี่ยวกับ Maven Build Cycle

วงจรชีวิตการสร้างแต่ละรายการถูกกำหนดโดยรายการของขั้นตอนการสร้างที่แตกต่างกันโดยที่เฟสการสร้างแสดงถึงระยะในวงจรชีวิต

ต่อไปนี้เป็นรายการขั้นตอนการสร้าง:

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

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

mvn แพ็คเกจที่สะอาด

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

ดังนั้นเราจะเริ่มต้นด้วยการรวบรวมซอร์สโค้ด ในแท็บ build คลิกที่เรียกใช้ maven ระดับบนสุดและพิมพ์คำสั่งด้านล่าง:

รวบรวม

พิจารณาภาพหน้าจอด้านล่าง:

สิ่งนี้จะดึงซอร์สโค้ดจากที่เก็บ GitHub และจะคอมไพล์ด้วย (Maven Compile Phase)

คลิกที่บันทึกและเรียกใช้โครงการ

ตอนนี้คลิกที่เอาต์พุตคอนโซลเพื่อดูผลลัพธ์

ขั้นตอน - 2 การทดสอบหน่วย:

ตอนนี้เราจะสร้างโครงการฟรีสไตล์อีก 1 โครงการสำหรับการทดสอบหน่วย

เพิ่ม URL ที่เก็บเดียวกันในแท็บการจัดการซอร์สโค้ดเหมือนที่เราทำในงานก่อนหน้านี้

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

  • ทริกเกอร์ก็ต่อเมื่อโครงสร้างมีเสถียรภาพ
  • ทริกเกอร์แม้ว่าโครงสร้างจะไม่เสถียร
  • ทริกเกอร์แม้ว่าการสร้างจะล้มเหลว

ฉันคิดว่าตัวเลือกข้างต้นค่อนข้างอธิบายตัวเองได้ดังนั้นให้เลือกตัวเลือกใดก็ได้ พิจารณาภาพหน้าจอด้านล่าง:

ในแท็บ Build คลิกที่เรียกใช้ maven ระดับบนสุดและใช้คำสั่งด้านล่าง:

ทดสอบ

เจนกินส์ยังช่วยคุณแสดงผลการทดสอบและแนวโน้มผลการทดสอบได้อย่างดีเยี่ยม

มาตรฐานโดยพฤตินัยสำหรับการรายงานการทดสอบในโลก Java คือรูปแบบ XML ที่ JUnit ใช้ รูปแบบนี้ยังใช้กับเครื่องมือทดสอบ Java อื่น ๆ อีกมากมายเช่น TestNG, Spock และ Easyb Jenkins เข้าใจรูปแบบนี้ดังนั้นหากบิวด์ของคุณสร้างผลการทดสอบ JUnit XML Jenkins สามารถสร้างรายงานการทดสอบแบบกราฟิกและสถิติที่ดีเกี่ยวกับผลการทดสอบเมื่อเวลาผ่านไปและยังให้คุณดูรายละเอียดของความล้มเหลวในการทดสอบ นอกจากนี้เจนกินส์ยังติดตามว่าการทดสอบของคุณใช้เวลานานเท่าใดทั้งในระดับโลกและต่อการทดสอบซึ่งอาจเป็นประโยชน์หากคุณต้องการติดตามปัญหาด้านประสิทธิภาพ

ดังนั้นสิ่งต่อไปที่เราต้องทำคือให้ Jenkins คอยติดตามการทดสอบหน่วยของเรา

ไปที่ส่วนการดำเนินการหลังการสร้างและเลือกช่องทำเครื่องหมาย 'เผยแพร่รายงานผลการทดสอบ JUnit' เมื่อ Maven รันการทดสอบหน่วยในโปรเจ็กต์ระบบจะสร้างรายงานการทดสอบ XML โดยอัตโนมัติในไดเร็กทอรีที่เรียกว่า surefire-reports. ดังนั้นให้ป้อน“ ** / target / surefire-reports / *. xml” ในช่อง“ Test report XMLs” เครื่องหมายดอกจันสองตัวที่จุดเริ่มต้นของเส้นทาง (“ **”) เป็นแนวทางปฏิบัติที่ดีที่สุดในการทำให้การกำหนดค่ามีประสิทธิภาพมากขึ้นเล็กน้อย: ช่วยให้ Jenkins ค้นหาไดเร็กทอรีเป้าหมายไม่ว่าเราจะกำหนดค่าให้ Jenkins ตรวจสอบซอร์สโค้ดอย่างไร

** / target / surefire-reports / *. xml

บันทึกอีกครั้งและคลิกที่สร้างทันที

ตอนนี้รายงาน JUnit เขียนถึง / var / lib / jenkins / workspace / test / gameoflife-core / target / surefire-reports / TEST-behavior

ในแดชบอร์ด Jenkinsคุณยังสามารถสังเกตเห็นผลการทดสอบ:

คุณสามารถเพิ่ม double เป็น int

ขั้นตอน - 3 การสร้างไฟล์ WAR และการปรับใช้บนเซิร์ฟเวอร์ Tomcat:

ตอนนี้ขั้นตอนต่อไปคือการรวมแอปพลิเคชันของเราไว้ในไฟล์ WAR และปรับใช้บนเซิร์ฟเวอร์ Tomcat เพื่อทดสอบการยอมรับของผู้ใช้

สร้างโปรเจ็กต์ฟรีสไตล์อีก 1 โปรเจ็กต์และเพิ่ม URL ที่เก็บซอร์สโค้ด

จากนั้นในแท็บ build trigger เลือก build เมื่อสร้างโปรเจ็กต์อื่นพิจารณาภาพหน้าจอด้านล่าง:

โดยทั่วไปหลังจากงานทดสอบขั้นตอนการปรับใช้จะเริ่มโดยอัตโนมัติ

ในแท็บบิลด์เลือกเชลล์สคริปต์ พิมพ์คำสั่งด้านล่างเพื่อทำแพ็กเกจแอปพลิเคชันในไฟล์ WAR:

แพ็คเกจ mvn

ขั้นตอนต่อไปคือการปรับใช้ไฟล์ WAR นี้กับ Tomcatเซิร์ฟเวอร์. ในแท็บ“ การดำเนินการหลังการสร้าง” เลือกปรับใช้ war / ear กับคอนเทนเนอร์ ที่นี่ให้เส้นทางไปยังไฟล์ war และให้เส้นทางบริบท พิจารณาภาพหน้าจอด้านล่าง:

เลือกข้อมูลประจำตัว Tomcat และสังเกตภาพหน้าจอด้านบน นอกจากนี้คุณต้องระบุ URL ของเซิร์ฟเวอร์ Tomcat ของคุณ

ในการเพิ่มข้อมูลรับรองใน Jenkins ให้คลิกที่ตัวเลือกข้อมูลรับรองบนแดชบอร์ด Jenkins

คลิกที่ระบบและเลือกข้อมูลรับรองส่วนกลาง

จากนั้นคุณจะพบตัวเลือกในการเพิ่มข้อมูลรับรอง คลิกที่มันและเพิ่มข้อมูลรับรอง

เพิ่มข้อมูลประจำตัว Tomcat พิจารณาภาพหน้าจอด้านล่าง

คลิกตกลง

ตอนนี้ในการกำหนดค่าโครงการของคุณให้เพิ่มข้อมูลรับรอง tomcat ที่คุณได้ใส่ไว้ในขั้นตอนก่อนหน้า

คลิกที่บันทึกจากนั้นเลือกสร้างทันที

ไปที่ URL ของคุณโดยใช้เส้นทางบริบทในกรณีของฉันคือ http: // localhost: 8081 ตอนนี้เพิ่มเส้นทางบริบทในตอนท้ายให้พิจารณาภาพหน้าจอด้านล่าง:

ลิงค์ - http: // localhost: 8081 / gof

ฉันหวังว่าคุณจะเข้าใจความหมายของเส้นทางบริบท

ตอนนี้สร้างมุมมองไปป์ไลน์พิจารณาภาพหน้าจอด้านล่าง:

คลิกที่ไอคอนบวกเพื่อสร้างมุมมองใหม่

กำหนดค่าไปป์ไลน์ตามที่คุณต้องการพิจารณาภาพหน้าจอด้านล่าง:

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

สุดท้ายคุณสามารถทดสอบไปป์ไลน์ได้โดยคลิกที่ RUN หลังจากทุก ๆ ห้านาทีหากมีการเปลี่ยนแปลงในซอร์สโค้ดท่อส่งทั้งหมดจะถูกดำเนินการ

ดังนั้นเราจึงสามารถปรับใช้แอปพลิเคชันของเราอย่างต่อเนื่องบนเซิร์ฟเวอร์ทดสอบสำหรับการทดสอบการยอมรับของผู้ใช้ (UAT)

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

ในการสร้างไปป์ไลน์ CI / CD คุณจำเป็นต้องฝึกฝนทักษะที่หลากหลาย เชี่ยวชาญทักษะ DevOps ที่จำเป็นตอนนี้