สร้างระบบอัตโนมัติและปรับใช้ระบบอัตโนมัติเทียบกับการรวมอย่างต่อเนื่อง


12

ฉันต้องการมีประสิทธิภาพมากขึ้นและต้องการใช้เครื่องมือ ops อย่างมีประสิทธิภาพ

ด้วยความคิดนี้ฉันต้องการเรียนรู้เพิ่มเติมเกี่ยวกับการรวมกลุ่มอย่างต่อเนื่อง แต่ดูเหมือนว่ามีหลายสิ่งที่เกี่ยวข้อง

จริง ๆ แล้วฉันทำงานกับชุด Jetbrains ในงานของฉัน (IntelliJ, WebStorm ... ) ดังนั้นฉันจึงต้องการใช้พวกเขาต่อไปและฉันต้องการใช้ TeamCity ซึ่งดูเหมือนจะเป็นเครื่องมือที่ยอดเยี่ยมกับปลั๊กอินจำนวนมากสำหรับการรวมอย่างต่อเนื่อง

ปัญหาของฉันคือฉันไม่รู้ว่าอะไรคือความแตกต่างระหว่าง:

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

  • การปรับใช้ระบบอัตโนมัติ (TeamCity ดูเหมือนจะไม่ทำอย่างง่ายดาย)

  • บูรณาการอย่างต่อเนื่อง (ซึ่งดูเหมือนว่าจะเป็นการรวมกันของทั้งสองข้างต้น)
  • การจัดส่งอย่างต่อเนื่อง (นี่คืออะไรจริง ๆ ทำไมมันแตกต่างจากการรวมอย่างต่อเนื่อง?)

คุณช่วยฉันเข้าใจเรื่องนี้ให้มากขึ้นได้ไหม?


มันเป็นระบบอัตโนมัติไม่ใช่ระบบอัตโนมัติ
Florian Margaine

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

คำตอบ:


15

Wikipedia ให้ข้อสรุปที่ดีเกี่ยวกับเงื่อนไขเหล่านี้ ที่นี่ฉันจะใช้เวลากับพวกเขา:

  • Build automationกำลังทำให้วิธีการสร้างซอฟต์แวร์โดยอัตโนมัติแทนที่จะเรียกใช้คอมไพเลอร์ด้วยตนเอง นี้จะทำได้ผ่านทางเครื่องมือเช่นเช่นยี่ห้อหรือมด

  • การปรับใช้แบบอัตโนมัติกำลังนำซอฟต์แวร์ที่สร้างขึ้นมาและนำไปใช้หรือติดตั้งในระบบทดสอบหรือระบบการผลิต

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

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

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

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

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


ดังนั้นเราสามารถยอมรับได้ว่าเครื่องมืออย่าง TeamCity ซึ่งอนุญาตให้สร้างบางสิ่งจาก VCS ระยะไกลอาจถือเป็นเซิร์ฟเวอร์ CI ได้หรือไม่ เช่นเดียวกับการรวมรหัส developper จากสาขา VCS และสร้างรุ่นล่าสุดจากเครื่องมืออัตโนมัติของอาคาร?
mfrachet

1
ผมไม่คุ้นเคยกับ TeamCity แต่มันดูเหมือนจะเป็นเซิร์ฟเวอร์ CI ประสบการณ์ส่วนใหญ่ของฉันอยู่กับเจนกินส์ CIรวมถึงการปรับใช้อัตโนมัติ

@Skahrz หากคุณต้องการปรับใช้อัตโนมัติคุณมีตัวเลือกเช่น BuildMaster (เช่นเซิร์ฟเวอร์ CI) และ Octopus Deploy
Andy

คุณกำลังอธิบายการสร้างอย่างต่อเนื่องแทนการรวมอย่างต่อเนื่อง หลังยังต้องตรวจสอบว่าสิ่งที่ใช้งานได้จริงเมื่อรวมกัน ..
Thorbjørn Ravn Andersen

@ ThorbjørnRavnAndersenคุณถูกต้องขอบคุณ ฉันอัพเดตคำตอบของฉันเพื่อพูดถึงการทดสอบกับ CI

0
  • การบูรณาการอย่างต่อเนื่องเป็นการฝึกการรวมการเปลี่ยนแปลงทั้งหมดของนักพัฒนาเข้าสู่การฉีดที่ใช้ร่วมกันหลายครั้งต่อวัน ตอนนี้การปฏิบัตินี้แพร่หลายจนไม่น่าจะเห็นได้ว่ามีความสำคัญอย่างไรก็ตามทีมงานดั้งเดิมจะทำงานกับซอฟต์แวร์เป็นเวลาหลายสัปดาห์หรือหลายเดือน ผลลัพธ์คือ "Integration Hell" เมื่อมีการรวมการทำงานแยกกันเข้าด้วยกัน การรวมอย่างต่อเนื่องโดยปกติจะใช้กับการสร้างอัตโนมัติของการฉีดที่ใช้ร่วมกันเพื่อค้นหาปัญหาก่อน

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

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

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

ฉันขอแนะนำให้อ่านหนังสือเล่มนี้สำหรับข้อมูลเพิ่มเติม:


-2

การทำงานเป็นทีมเหมือนกับเครื่องมือสร้างหลายอย่างเป็นเพียงแอพส่วนกลางที่ให้คุณเรียกใช้งานที่แตกต่างกันมากมาย ซึ่งรวมถึงงานสร้างที่มีประสิทธิภาพเช่นงานสร้าง CI, งานวางบิลเต็มรูปแบบและช่วยให้คุณสามารถปรับใช้งานได้ หากคุณใช้ teamcity เพื่อโทรหา ant หรือ nant เพื่อรัน msbuild บนไฟล์โซลูชันคุณยังสามารถเรียกใช้สคริปต์ nant ที่จะใช้งานได้ อาจต้องใช้สคริปต์เล็กน้อย แต่ก็ไม่ยาก

เราใช้ teamcity และไผ่สำหรับ CI ทั้งหมด, ฐานข้อมูล CI และปรับใช้กับสภาพแวดล้อมแบบอินทิเกรชั่น จากนั้นเราใช้ teamcity สำหรับการสร้างและสร้างสคริปต์การย้ายข้อมูลโดยอัตโนมัติ สิ่งเหล่านี้ถูกตรวจสอบใน SVN ผ่านงานของทีมที่เรียกใช้สคริปต์ที่ไม่ต้องการ สำหรับ deploys คุณเดาว่าเราใช้ teamcity เพื่อโทรหา nant เพื่อดำเนินการปรับใช้ วิธีนี้ทำงานได้ดีเนื่องจากเอเจนต์ teamcity พูดคุยกับเซิร์ฟเวอร์ teamcity และเอเจนต์สามารถมีอยู่บนหนึ่งในเซิร์ฟเวอร์ในตำแหน่ง DMZ ซึ่งช่วยในการย้ายรหัสนอกเหนือจากไฟร์วอลล์ ฯลฯ ดังนั้น teamcity หรือไผ่จึงเป็นสิ่งที่คุณต้องจัดการกับสถานการณ์ทั้งหมด .


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