คุณใช้กรอบการรวมต่อเนื่องแบบใดและเพราะเหตุใด [ปิด]


21

มีกรอบการทำงานร่วมกันอย่างต่อเนื่อง (CI) ที่แตกต่างกันออกไปเล็กน้อยและฉันสงสัยว่าสิ่งใดที่ได้รับความนิยมมากที่สุด กรอบการทำงานแบบใดที่คุณใช้ใน บริษัท ที่คุณทำงาน

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

ดูเหมือนว่ามีการใช้การรวมอย่างต่อเนื่องในโลก Java และ. net มากกว่าการพูดว่า ruby ​​หรือ python ทำไมนี้


หนึ่งในเหตุผลที่ CI ไม่เกี่ยวข้องกับ Ruby และ Python ก็คือภาษานั้นถูกตีความดังนั้นไม่จำเป็นต้องรวบรวมอะไรเลย แต่นั่นเป็นเพียงความเห็นส่วนตัวของฉัน ...
mliebelt

1
@mliebelt --CI ขยายไปมากกว่าการรวบรวมเช็ค คุณสามารถเรียกใช้การทดสอบหน่วย / บูรณาการ (แม้จะมีโครงการขึ้นอยู่กับอื่น ๆ )
Apoorv Khurasia

คำตอบ:


31

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

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


ฉันจะเพิ่ม UI ที่ดีให้กับสิ่งนี้เช่นกัน
Martijn Verburg

ใช่ฉันจะสรุป UI ภายใต้การใช้งานง่าย
Mnementh

5
CruiseControl เป็นความเจ็บปวดที่เกิดขึ้น ... ฮัดสันนั้นง่ายมากที่จะลุกขึ้นวิ่ง ปลั๊กอินChuck Norris ( wiki.hudson-ci.org/display/HUDSON/ChuckNorris+Plugin ) เป็นสิ่งที่ต้องมี
Sam Dolan

ฮัดสันนั้นยอดเยี่ยมจริงๆ แม้ว่าฉันหวังว่ามันจะดีกว่าที่แยก หากคุณมีทีมงานที่แตกต่างกันจำนวนมากที่ทำงานในโครงการที่เกี่ยวข้องอย่างหลวม ๆ โอกาสในการก้าวเท้าของกันและกันก็สูงมาก
Greg Gauthier

โปรแกรมเมอร์นี้ยังไม่สามารถกำหนดค่าฮัดสันให้ทำงานบน Windows :(
Mchl

16

ฉันใช้TeamCityที่ทำงานและที่บ้าน มันมีการสนับสนุนที่ดีสำหรับนักวิ่งที่หลากหลายและสามารถขยายได้ผ่านทางปลั๊กอิน

การไม่จัดการกับกอง XML สำหรับการตั้งค่าเป็นข้อดีอย่างมากในหนังสือของฉันและรุ่นฟรีนั้นเพียงพอสำหรับความต้องการในบ้านของฉัน

ปัญหาหนึ่งที่ฉันพบกับ TeamCity คือการพยายามทำให้แอสเซมบลี. NET เวอร์ชันอัตโนมัติ ฉันต้องตั้งวิธีแก้ปัญหาที่ค่อนข้างซับซ้อน แต่เมื่อมันเข้าที่แล้วมันก็ทำงานได้เหมือนมีเสน่ห์


ฉันจะลองใช้ TC ที่บ้าน เราไม่มีอะไรนอกจากมีปัญหากับ cruisecontrol.net
ไม่มีใคร

8

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

ที่กล่าวว่ามีข้อเสนอการค้าสองสามอย่างที่ฉันทราบ (หนึ่งโดย JetBrains, อื่น ๆ โดย Atlassian) ซึ่งเสนอประสบการณ์ที่ดีขึ้นและการสนับสนุนเชิงพาณิชย์ ฉันตั้งใจจะลองใช้ข้อเสนอเหล่านี้ แต่จริงๆแล้วยังไม่มีโอกาส

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

มีปัญหาทั่วไปสามประเภทที่เครื่องมือ CI สามารถช่วยคุณได้:

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

ภาษาที่ตีความไม่ได้รวบรวมดังนั้นจึงไม่มีข้อผิดพลาดในการรวบรวมที่จะจับ อย่างไรก็ตามปัญหาอีกสองปัญหานั้นเป็นเรื่องธรรมดามากพอที่เครื่องมือ CI จะมีประโยชน์สำหรับโครงการใน Ruby / Python / Perl / etc

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

แก้ไข

ดูแผนภูมิที่ดีสำหรับการเปรียบเทียบคุณสมบัติของ CI Tools จำนวนมาก (ซึ่งส่วนมากที่ฉันไม่รู้):

http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix


ความแตกต่างที่รวบรวม / ตีความไม่ได้เป็นสีดำและสีขาว ตัวอย่างเช่น Perl มีเฟสคอมไพล์ที่ทำงานเมื่อเริ่มต้น (และสามารถเรียกใช้แยกต่างหากด้วยตัวเลือก "-c") เพื่อตรวจสอบข้อผิดพลาดทางไวยากรณ์
Andrew Medico

นี่เป็นเรื่องจริง Ruby 1.9 และ Python ยังมีขั้นตอนการคอมไพล์ ปัญหาข้อผิดพลาดในการรวบรวมระดับใช้กับภาษาใด ๆ ที่จะแจ้งเตือนคุณหากคลาส / ตัวแปร / วิธีการอ้างอิงไม่มีอยู่ในระหว่างการรวบรวม แน่นอนมันใช้กับภาษาที่พิมพ์แบบคงที่ใด ๆ YMMV สำหรับภาษาที่พิมพ์แบบไดนามิก แต่แข็งแรง (เช่น Ruby และ Python)
Berin Loritsch

"เมื่อคุณตั้งค่าแล้วคุณจะต้องทำสิ่งเล็ก ๆ น้อย ๆ เพื่อรักษามัน" - นั่นไม่เป็นความจริงเลยที่เซิร์ฟเวอร์รวมอย่างต่อเนื่องทั้งหมดหรือไม่
ไบรอัน Oakley

5

เซิร์ฟเวอร์มูลฐานทีม

CI แข็ง, ผนวกกับ Visual Studio และGit เป็นการควบคุมเวอร์ชัน ฉันเห็นเซิร์ฟเวอร์ CI ที่ยืดหยุ่นมากขึ้นเช่นฮัดสัน แต่การผนวก TFS กับผลิตภัณฑ์อื่น ๆ อย่างแน่นหนาทำให้ประสบการณ์นั้นราบรื่นมากจนเหมาะสมสำหรับทีมของฉัน


โดย 'ผลิตภัณฑ์อื่น' คุณหมายถึง 'ผลิตภัณฑ์ของ Microsoft' ฉันไม่ได้วิจารณ์คุณ แต่ MS มีโครงสร้างกองเทคโนโลยีของพวกเขาเพื่อที่จะรวมเข้ากับผลิตภัณฑ์ MS คุณต้องมีผลิตภัณฑ์ MS อื่น ๆ หรือมีความอดทนและ / หรือความเพียรมาก
GKelly

1
เรื่องไร้สาระที่สุด. พวกเขามี API และ SDK สำหรับเกือบทุกอย่างที่พวกเขาทำแม้แต่ Kinect แต่โปรแกรมเมอร์ที่ไม่ใช่ MS ก็ไม่รู้เพราะปิดหูทันทีที่ได้ยิน Micros .. (ลิงก์ไปยัง TFS SDK) msdn.microsoft.com/ en-us / library / bb130146 (v = VS.80) .aspx
Luke Puplett

2

ฉันใช้ทั้งCruiseControl.NETและHudsonฮัดสันงานสร้างของฉันบางอย่างอยู่บนหนึ่งในนั้นและบางงานอยู่ในที่อื่น

ทำไม? เพราะฉันไม่ใช่วิศวกรสร้างและเขาที่เป็นวิศวกรสร้างตั้งพวกเขาด้วยวิธีนี้!

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

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


1

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


1

ทีมงานของเราทำงานเป็นหลักใน Python, C ++ และ Java เราใช้ Buildbot สำหรับ CI เริ่มแรกเราเริ่มต้นด้วยเพราะมันรวมกับ Trac และเพราะมันดูง่ายและตรงไปตรงมา ฉันเชื่อว่าเป็นกรอบการทำงาน CI ของทางเลือกในโลก Python


1

ฮัดสัน บางครั้งมันก็บั๊กเล็กน้อยและปลั๊กอินที่น่าสนใจบางตัวก็ใช้งานไม่ได้ แต่ด้วยการใช้งานเล็กน้อยมันก็ใช้ได้ดี

ฉันอาจจะใช้ Pulse แทน แต่ถ้าคุณต้องการสร้างในหลาย ๆ แพลตฟอร์มมันคือ> $ 5k ซึ่งค่อนข้างมาก


1

CruiseControl.NETเพื่อการรวมอย่างต่อเนื่อง ทำงานได้ค่อนข้างดีแม้ว่าจะมีโครงการสร้างจำนวนมากที่เราได้ติดตั้งไว้ใน CruiseControl แอพถาดใส่เดสก์ท็อป CCTray นั้นไม่ตอบสนองอย่างน่ากลัวแม้จะมีช่วงเวลารีเฟรชที่ยาวนาน

NAntสำหรับสคริปต์ที่ถูกเรียกใช้งานในโครงการ CruiseControl สำหรับสคริปต์บิลด์ที่ซับซ้อนมากขึ้นเราได้ขยาย NAnt ด้วยงาน C # NAnt ที่กำหนดเองซึ่งดีมาก - การเขียนโค้ดใน C # นั้นสนุกกว่าการสร้างสคริปต์ NAnt

เราเป็นร้านค้าของ Microsoft และในทางทฤษฎีแล้วจะย้ายไปที่ Team Build 2010 ของ Microsoft เมื่อเราย้ายสภาพแวดล้อม Team Foundation Server ไปเป็น 2010


0

โปรดทราบว่าคุณควรจะสามารถสร้างแอปพลิเคชันของคุณจากบรรทัดคำสั่งไม่ว่าคุณจะมี CI-engine ทำงานหรือไม่ก็ตาม

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

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

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


0

ก่อนที่ฉันจะเคยได้ยินคำว่า "การบูรณาการอย่างต่อเนื่อง" (ย้อนกลับไปเมื่อปี 2545 หรือ 2546) ฉันเขียนสคริปต์ตอนกลางคืนที่เชื่อมต่อกับ CVS คว้าสำเนาโครงการหลักที่สะอาดและโครงการย่อยขนาดเล็กห้าโครงการสร้างทั้งหมด jars ผ่าน ant แล้วสร้างและปรับใช้ไฟล์ WAR อีกครั้งผ่านสคริปต์ ant ตัวที่สองที่ใช้งาน tomcat ant

มันวิ่งผ่าน cron เวลา 19.00 น. และส่งอีเมลพร้อมไฟล์เอาต์พุตจำนวนมากที่แนบมา เราใช้มันตลอดทั้ง 7 เดือนของโครงการและมันใช้งานได้ในอีก 20 เดือนของการบำรุงรักษาและปรับปรุง

มันทำงานได้ดี แต่ก็ยังชอบฮัดสันมากกว่าสคริปทุบตี cron และ ant

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.