การจัดส่งต่อเนื่อง:
การจัดส่งแบบต่อเนื่องเป็นกระบวนการที่การเปลี่ยนแปลงโค้ดจะถูกสร้างขึ้นทดสอบและเตรียมสำหรับการนำไปใช้งานจริงโดยอัตโนมัติฉันหวังว่าคุณจะสนุกกับไฟล์ ที่นี่ฉันจะพูดถึงหัวข้อต่อไปนี้ ::
- การจัดส่งแบบต่อเนื่องคืออะไร?
- ประเภทของการทดสอบซอฟต์แวร์
- ความแตกต่างระหว่างการรวมการส่งมอบและการปรับใช้อย่างต่อเนื่อง
- ความต้องการในการจัดส่งแบบต่อเนื่องคืออะไร?
- ลงมือใช้ Jenkins และ Tomcat
ให้เราเข้าใจอย่างรวดเร็วว่าการจัดส่งแบบต่อเนื่องทำงานอย่างไร
การจัดส่งแบบต่อเนื่องคืออะไร?
เป็นกระบวนการที่คุณสร้างซอฟต์แวร์ในลักษณะที่สามารถเผยแพร่สู่การผลิตได้ตลอดเวลาพิจารณาแผนภาพด้านล่าง:
ให้ฉันอธิบายแผนภาพด้านบน:
- สร้างสคริปต์อัตโนมัติจะตรวจจับการเปลี่ยนแปลงใน 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 ที่จำเป็นตอนนี้