GitLab CI กับ Jenkins [ปิด]

อะไรคือความแตกต่างระหว่าง Jenkins และ CI อื่น ๆ เช่น GitLab CI, drone.io ที่มาพร้อมกับการกระจาย Git ในการวิจัยบางอย่างฉันสามารถทำได้เพียงว่า GitLab community edition ไม่อนุญาตให้เพิ่ม Jenkins แต่ GitLab enterprise edition ทำ มีความแตกต่างที่สำคัญอื่น ๆ หรือไม่?

นี่คือประสบการณ์ของฉัน:

ที่ทำงานของฉันเราจัดการที่เก็บของเราด้วย GitLab EE และเรามีเซิร์ฟเวอร์ Jenkins (1.6) ที่ทำงานอยู่

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

TL; DR;

• Jenkins ใช้ / เรียนรู้ได้ง่ายกว่า แต่ก็มีความเสี่ยงที่จะกลายเป็นนรกของปลั๊กอิน
• Jenkins มี GUI (สิ่งนี้สามารถเลือกใช้ได้หากคนอื่นต้องเข้าถึง / บำรุงรักษาได้)
• การรวมกับ GitLab น้อยกว่า GitLab CI
• Jenkins สามารถแยกออกจากที่เก็บของคุณได้

เซิร์ฟเวอร์ CI ส่วนใหญ่ค่อนข้างตรงไปตรงมา ( concourse.ci ), gitlab-ci , circle-ci , travis-ci , drone.io , gocdและคุณมีอะไรอีกบ้าง) อนุญาตให้คุณรันสคริปต์เชลล์ / แบ็ตจากข้อกำหนดไฟล์ YAML Jenkins สามารถเสียบปลั๊กได้มากกว่าและมาพร้อมกับ UI อาจเป็นข้อดีหรือข้อเสียก็ได้ขึ้นอยู่กับความต้องการของคุณ

เจนกินส์สามารถกำหนดค่าได้มากเนื่องจากปลั๊กอินทั้งหมดที่มีอยู่ ข้อเสียคือเซิร์ฟเวอร์ CI ของคุณอาจกลายเป็นปลั๊กอินสปาเก็ตตี้

ในความคิดของฉันการผูกมัดและการจัดระเบียบงานในเจนกินส์นั้นง่ายกว่ามาก (เนื่องจาก UI) มากกว่าผ่าน YAML (การเรียกคำสั่ง curl) นอกจากนั้น Jenkins ยังรองรับปลั๊กอินที่จะติดตั้งไบนารีบางตัวเมื่อไม่สามารถใช้งานได้บนเซิร์ฟเวอร์ของคุณ (ไม่รู้เกี่ยวกับปลั๊กอินอื่น ๆ )

ปัจจุบัน ( Jenkins 2ยังสนับสนุน "ci ที่เหมาะสม" มากขึ้นด้วยJenkinsfileและปลั๊กอินpiplineซึ่งมาจากค่าเริ่มต้นของ Jenkins 2) แต่เคยใช้คู่กับที่เก็บน้อยกว่าเช่น GitLab CI

การใช้ไฟล์ YAML เพื่อกำหนด build pipeline ของคุณ (และในที่สุดการรัน pure shell / bat) จะสะอาดกว่า

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

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

• เอกสารของพวกเขาจะช่วยให้คุณเริ่มต้นได้ในเวลาไม่นาน
• เกณฑ์ในการเริ่มต้นต่ำมาก
• การบำรุงรักษาทำได้ง่าย (ไม่มีปลั๊กอิน)
• การปรับขนาดของนักวิ่งเป็นเรื่องง่าย
• CI เป็นส่วนหนึ่งของที่เก็บของคุณอย่างสมบูรณ์
• งาน / มุมมองของเจนกินส์อาจยุ่งเหยิง

สิทธิประโยชน์บางอย่างในขณะที่เขียน:

• สนับสนุนเฉพาะไฟล์เดียวในฉบับชุมชน ไฟล์หลายรายการในฉบับขององค์กร

ฉันเห็นด้วยกับบันทึกส่วนใหญ่ของ Rik แต่ความคิดเห็นของฉันเกี่ยวกับข้อใดที่ง่ายกว่านั้นตรงกันข้าม : GitLab พิสูจน์แล้วว่าเป็นเครื่องมือที่ยอดเยี่ยมในการใช้งาน

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

ตอนนี้ฉันกำลังใช้มันเพื่อทำการอัตโนมัติและทดสอบว่าแอปพลิเคชันติดตั้งบนลีนุกซ์รุ่นต่างๆอย่างไรและเพียงแค่กำหนดค่าได้อย่างรวดเร็ว (ลองเปิดการกำหนดค่างานเจนกินส์ที่ซับซ้อนใน Firefox และรอให้สคริปต์ที่ไม่ตอบสนองปรากฏขึ้นเทียบกับ . วิธีแก้ไขน้ำหนักเบา.gitlab-ci.yml).

เวลาที่ใช้ในการกำหนดค่า / ปรับทาสเป็นอย่างมากขอบคุณน้อยกับไบนารีวิ่ง ; บวกกับความจริงที่ว่าในGitLab.comคุณจะได้นักวิ่งที่ใช้งานร่วมกันได้ดีและฟรี

เจนกินส์รู้สึกมีความเป็นตัวของตัวเองมากขึ้นหลังจากผ่านไปหลายสัปดาห์ในการเป็นผู้ใช้ GitLab CI เช่นการทำซ้ำงานต่อสาขาการติดตั้งปลั๊กอินเพื่อทำสิ่งง่ายๆเช่นการอัปโหลด SCP กรณีการใช้งานเดียวที่ฉันต้องเผชิญในที่ที่ฉันพลาดในวันนี้คือเมื่อมีที่เก็บมากกว่าหนึ่งที่เกี่ยวข้อง ที่ต้องคิดให้ดี

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

ก่อนอื่น ณ วันนี้ GitLab Community Edition สามารถทำงานร่วมกับ Jenkins ได้อย่างสมบูรณ์ ไม่มีคำถาม.

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

ฉันหวังว่านี่จะให้ข้อมูลที่มีคุณภาพเกี่ยวกับโครงการของคุณเอง

จุดแข็งของ GitLab CI และ Jenkins

GitLab CI

GitLab CI รวมอยู่ใน GitLab SCM อย่างเป็นธรรมชาติ คุณสามารถสร้างไปป์ไลน์โดยใช้gitlab-ci.ymlไฟล์และจัดการผ่านอินเทอร์เฟซแบบกราฟิก

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

GitLab CI เป็นเครื่องมือจัดการภาพที่ยอดเยี่ยม:

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

เจนกินส์

Jenkins เป็นเครื่องมือสร้างที่ยอดเยี่ยม จุดเด่นอยู่ที่ปลั๊กอินจำนวนมาก โดยเฉพาะอย่างยิ่งฉันโชคดีในการใช้ปลั๊กอินอินเทอร์เฟซระหว่างเจนกินส์กับเครื่องมือ CI หรือซีดีอื่น ๆ นี่เป็นตัวเลือกที่ดีกว่าการพัฒนาอินเทอร์เฟซการโต้ตอบระหว่างสององค์ประกอบใหม่ (อาจไม่ดี)

Pipeline เป็นรหัสสามารถใช้ได้โดยใช้ groovyสคริปต์

ใช้ GitLab CI และ Jenkins ร่วมกัน

ในตอนแรกอาจฟังดูซ้ำซ้อนเล็กน้อย แต่การรวม GitLab CI และ Jenkins นั้นมีประสิทธิภาพมาก

• GitLab CI จัดระเบียบไปป์ไลน์ (เชนรันมอนิเตอร์ ...
• เจนกินส์ทำงานและอำนวยความสะดวกในการโต้ตอบกับเครื่องมือของบุคคลที่สาม

ข้อดีอีกอย่างของการออกแบบนี้คือการมีข้อต่อหลวมระหว่างเครื่องมือ:

• เราสามารถเปลี่ยนส่วนประกอบของโรงงานสร้างโดยไม่ต้องทำกระบวนการ CI / CD ใหม่ทั้งหมด
• เราสามารถมีสภาพแวดล้อมการสร้างที่แตกต่างกันโดยรวม Jenkins, TeamCity (อาจเป็นหลายตัว), คุณตั้งชื่อและยังมีเครื่องมือตรวจสอบเดียว

การแลกเปลี่ยน

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

ด้วยเหตุนี้ฉันจึงไม่แนะนำให้ตั้งค่าดังกล่าวเว้นแต่

• คุณมีเครื่องมือของบุคคลที่สามมากมายให้จัดการ นั่นคือตอนที่ Jenkins มาพร้อมกับปลั๊กอินมากมาย
• คุณต้องจัดการกับแอปพลิเคชันที่ซับซ้อนด้วยเทคโนโลยีที่แตกต่างกันมีสภาพแวดล้อมการสร้างที่แตกต่างกันและยังต้องมี UI การจัดการวงจรชีวิตของแอปพลิเคชันแบบรวม

หากคุณไม่อยู่ในสถานการณ์เหล่านี้คุณอาจจะดีกว่าที่จะมีเพียงหนึ่งในสองสถานการณ์ แต่ไม่ใช่ทั้งสองอย่าง

ถ้าฉันต้องเลือก

ทั้ง GitLab CI และ Jenkins มีข้อดีข้อเสีย ทั้งสองเป็นเครื่องมือที่มีประสิทธิภาพ แล้วจะเลือกอันไหนดี?

คำตอบ 1

เลือกคนที่ทีมของคุณ (หรือคนใกล้ชิด) มีความเชี่ยวชาญระดับหนึ่งแล้ว

คำตอบ 2

หากคุณเป็นนักศึกษาใหม่ในเทคโนโลยี CI เพียงแค่เลือกหนึ่งและเริ่มต้นใช้งาน

• หากคุณใช้ GitLab และมีความสามารถพิเศษสำหรับทุกอย่างเป็นรหัสคุณควรเลือก GitLab CI
• หากคุณต้องพูดคุยกับเครื่องมือ CI / CD อื่น ๆ หรือต้องการ GUI นั้นในการสร้างงานของคุณอย่างแท้จริงให้ไปที่ Jenkins

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

คำสุดท้ายคือ: ความสมดุลเอนเอียงไปทางเจนกินส์เล็กน้อยเนื่องจากมีปลั๊กอินจำนวนมาก แต่มีโอกาสที่ GitLab CI จะเติมเต็มช่องว่างได้อย่างรวดเร็ว

ฉันต้องการเพิ่มสิ่งที่ค้นพบจากการทดลองล่าสุดของฉันกับ GitLab CI ฟีเจอร์ที่มาพร้อมกับ 11.6 และ 11.7 นั้นยอดเยี่ยมมาก!

โดยเฉพาะฉันชอบonlyเงื่อนไขที่โดยพื้นฐานแล้วอนุญาตให้คุณสร้างท่อแยกสำหรับmerge_requestหรือpush(รายการทั้งหมดอยู่ที่นี่ )

นอกจากนี้ฉันชอบที่ไม่มีปลั๊กอิน เมื่อฉันต้องการฟังก์ชั่นที่ซับซ้อนมากขึ้นฉันก็แค่เขียนอิมเมจ Docker ที่กำหนดเองซึ่งจัดการกับฟังก์ชันที่จำเป็น (เป็นแนวคิดเดียวกับที่คุณเห็นในdrone.io )

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

.myTemplate:
  image: node:10.14.2
  script:
    - npm install
    - npm run test

นำไปไว้ในที่เก็บสาธารณะรวมไว้ในท่อหลัก:

include:
  - remote: https://....

และใช้เพื่อขยายงาน:

test:
  extends: .myTemplate
  only:
    refs: ["master"]
    variables:
      - $CI_PIPELINE_SOURCE == "push"

ฉันรัก GitLab CI มาก!ใช่มัน (จนถึงตอนนี้) ไม่สามารถวาดกราฟที่สวยงามพร้อมความครอบคลุมและอื่น ๆ ได้ แต่โดยรวมแล้วมันเป็นเครื่องมือที่ประณีตจริงๆ!

แก้ไข (2019-02-23): นี่คือโพสต์ของฉันเกี่ยวกับสิ่งที่ฉันชอบใน GitLab CI มันเขียนขึ้นในยุค 11.7 ดังนั้นเมื่อคุณอ่านคำตอบนี้ GitLab CI อาจมีคุณสมบัติอื่น ๆ อีกมากมาย

แก้ไข (2019-07-10):ตอนนี้ Gitlab CI รองรับหลายตัวextendsเช่น

extends:
 - .pieceA
 - .pieceB

ตรวจสอบเอกสารอย่างเป็นทางการเพื่อรับข้อมูลเพิ่มเติมเกี่ยวกับการขยายหลายรายการ

หากงานสร้าง / เผยแพร่ / ปรับใช้และทดสอบของคุณไม่ซับซ้อนมากการใช้ gitlab ci ก็มีข้อดีตามธรรมชาติ

เนื่องจาก gitlab-ci.yml แสดงควบคู่ไปกับโค้ดของคุณในทุกสาขาคุณจึงสามารถปรับเปลี่ยนขั้นตอน ci / cd โดยเฉพาะการทดสอบ (ซึ่งแตกต่างกันไปตามสภาพแวดล้อม) ได้อย่างมีประสิทธิภาพมากขึ้น

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

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

นอกจากนี้ gitlab ci จะเช็คอินให้คุณโดยอัตโนมัติและคุณไม่จำเป็นต้องจัดการเจนกินส์มาสเตอร์แยกต่างหาก