คำถามติดแท็ก continuous-integration

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

17 version-control  continuous-integration 

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

16 testing  development-process  scrum  continuous-integration  workflows 

ฉันยังเป็นผู้ใช้โค่นล้มคนหนึ่งที่พยายามให้ความรู้แก่ตัวเองอีกครั้งในการควบคุมเวอร์ชันแบบกระจาย เมื่อใช้การโค่นล้มฉันเป็นแฟนตัวยงของวิธีการย่อยโครงการและกับอดีตนายจ้างส่วนใหญ่ของฉันเราจะจัดโครงสร้างสาขาที่เก็บของเรา แท็ก & ลำต้นดังนี้: branches-+ +-personal-+ | +-alice-+ | | +-shinyNewFeature | | +-AUTOMATED-+ | | +-shinyNewFeature | +-bob-+ | +-AUTOMATED-+ | +-bespokeCustomerProject +-project-+ +-shinyNewFeature +-fixStinkyBug tags-+ +-m20110401_releaseCandidate_0_1 +-m20110505_release_0_1 +-m20110602_milestone trunk ภายในต้นไม้ต้นกำเนิดจริงเราจะใช้โครงสร้างคล้ายกันดังต่อไปนี้ (src)-+ +-developmentAutomation-+ | +-testAutomation | +-deploymentAutomation | +-docGeneration | +-staticAnalysis | +-systemTest | +-performanceMeasurement | +-configurationManagement | …

16 mercurial  organization  continuous-integration  svn  configuration-management 

ฉันกำลังพยายามเพิ่มการรวมอย่างต่อเนื่องในโครงการ ตามวิกิพีเดียหนึ่งในชิ้นส่วนที่สำคัญของ CI คือการสร้างอัตโนมัติ อย่างไรก็ตามฉันสับสนเกี่ยวกับสิ่งที่หมายถึงว่าเป็น CI และสร้างบทความอัตโนมัติดูเหมือนจะไม่เห็นด้วย จุดเฉพาะของความสับสน: "การสร้างอัตโนมัติ" หมายถึงอะไรในบริบทของ: โครงการที่ใช้ภาษาที่ตีความเช่น Python หรือ Perl สร้างจากแหล่งที่มาบนเครื่องของผู้ใช้ปลายทาง? แอปพลิเคชันที่มีการขึ้นต่อกันที่ไม่สามารถรวบรวมและแจกจ่ายได้ง่ายเช่นฐานข้อมูลใน RDBMS แบบโลคัลไปยังเครื่องของผู้ใช้หรือไม่?

15 continuous-integration  automation  builds 

ฉันเป็นผู้จัดการโครงการที่ บริษัท ของฉัน ฉันทำงานกับนักพัฒนาไม่กี่ทีมโดยใช้ระบบควบคุมเวอร์ชันมาตรฐานที่รู้จักกันดีที่เรียกว่า CVS ฉันต้องการดูการรวมอย่างต่อเนื่องและการสร้างอัตโนมัติที่ดำเนินการเพื่อช่วยป้องกันปัญหาเกี่ยวกับการทำลายการสร้างและการปรับใช้ที่ไม่ดีด้อมไปที่เซิร์ฟเวอร์การผลิต ฉันแน่ใจว่าฉันสามารถตั้งค่านี้เอง แต่ฉันไม่ต้องการทำสิ่งนี้ด้วยตัวเองด้วยเหตุผลสองประการ: ฉันไม่มีเวลาสำหรับมัน ฉันมีความรับผิดชอบของตัวเองซึ่งเกี่ยวข้องกับการตลาดการสื่อสารกับผู้มีส่วนได้เสียอื่น ๆ กับสมาชิกในทีมที่ไม่ได้เป็นส่วนหนึ่งของการพัฒนาสื่อสารกับลูกค้าและการวางแผนโครงการ ที่สำคัญที่สุดคือฉันเป็นผู้จัดการโครงการ จุดประสงค์ของฉันคือการให้ความเป็นผู้นำไม่ให้ไมโครจัดการทีมพัฒนา ฉันสามารถทำอะไรเพื่อค้นหาคนในทีมพัฒนาที่จะหลงใหลในการตั้งค่านี้ นักพัฒนาเป็นบุคคลที่เหมาะสมสำหรับงานนี้หรือไม่เนื่องจากต้องใช้ความรู้เกี่ยวกับ Java, Spring และ Google App Engine มีเคล็ดลับอะไรบ้างในการช่วยส่งเสริมการเปลี่ยนแปลงเมื่อกลัวว่าจะมีการเปลี่ยนแปลง

15 version-control  continuous-integration  change 

ฉันเพิ่งเปลี่ยนการตั้งค่าสาขาในที่เก็บ GitHub ของฉันดังนั้นสาขา [ถัดไป] ของฉันต้องผ่านการสร้าง CI ผ่านคำขอดึง การสนทนาตามด้วยสมาชิกในทีมจำนวนหนึ่งเกี่ยวกับการทดสอบที่ล้มเหลว เพื่อบริบทของ ... ที่เก็บมีสาขา [master] ที่มีการประชาสัมพันธ์เพียงอย่างเดียวเมื่อมีการเปิดตัวดังนั้น [master] มีรหัสณวันที่ออกล่าสุดโดยไม่คำนึงว่าสาขาใหญ่ผู้เยาว์โปรแกรมแก้ไขด่วนเบต้าหรือ alpha / รุ่นก่อนวางจำหน่าย สาขา [ถัดไป] เป็นสาขา "ค่าเริ่มต้น" โดยที่เราต้องการเก็บรหัส "พร้อมใช้" ในทางเทคนิคสาขานั้นสามารถประชาสัมพันธ์ให้เป็น [master] ได้ตลอดเวลาและได้รับการปล่อยตัว ส้อมแต่ละคนมีกิ่ง dev ของตัวเองและผู้สนับสนุน PR ถึง [ถัดไป] เมื่อฉันตรวจทาน PR ที่ไม่สำคัญฉันจะรวมสาขา dev ของผู้มีส่วนร่วมในสาขา "review" ของฉันและถ้าฉันเห็นสิ่งที่ฉันสามารถแก้ไขได้อย่างรวดเร็วฉันจะยอมรับ / ผลักดันการเปลี่ยนแปลงและการทดสอบใหม่ (บางครั้งล้มเหลว) และ PR กลับไปที่สาขานักพัฒนาของผู้มีส่วนร่วม; เมื่อพวกเขารวมการเปลี่ยนแปลงของฉันทำการทดสอบความล้มเหลวใหม่ผ่านแล้วผลัก PR ของพวกเขาประสานและจากนั้นฉันจะรวมการประชาสัมพันธ์เป็น [ถัดไป] …

14 unit-testing  git  teamwork  continuous-integration 

เมื่อมีการรวมอย่างต่อเนื่องในการดำเนินการทดสอบในแต่ละการกระทำแนวทางปฏิบัติที่ดีที่สุดคือการทดสอบทั้งหมดที่ผ่านตลอดเวลา (หรือที่รู้จักว่า ฉันพบปัญหาบางอย่างกับที่: ตัวอย่างหนึ่งไม่สามารถช่วยโครงการโอเพ่นซอร์สโดยการสร้างการทดสอบที่สอดคล้องกับตั๋ว ฉันรู้ว่าฉันเสนอ Pull Request ให้กับโปรเจคโอเพ่นซอร์สที่มีการทดสอบความล้มเหลวบิลด์จะถูกทำเครื่องหมายว่าล้มเหลวและโปรเจ็กต์จะไม่ต้องการรวมเข้ากับที่เก็บเพราะมันจะ "ทำลายบิลด์" และฉันไม่เชื่อว่ามันเป็นสิ่งที่ไม่ดีที่มีการทดสอบที่ล้มเหลวใน repo ของคุณเหมือนมีปัญหาในตัวติดตามของคุณ สิ่งเหล่านี้เป็นเพียงสิ่งที่รอการแก้ไข เช่นเดียวกับใน บริษัท หากคุณทำงานกับ TDD คุณจะไม่สามารถเขียนทดสอบกระทำและเขียนรหัสตรรกะที่ทำแบบทดสอบได้ นั่นหมายความว่าถ้าฉันเขียนแบบทดสอบ 4-5 เรื่องบนแล็ปท็อปของฉันฉันไม่สามารถยืนยันได้ก่อนวันหยุด ไม่มีใครสามารถคืนงานของฉันได้ ฉันไม่สามารถแม้แต่ "แบ่งปัน" กับเพื่อนร่วมงานได้ยกเว้นโดยการส่งทางอีเมลเช่น นอกจากนี้ยังป้องกันการทำงานกับคนคนหนึ่งที่เขียนแบบทดสอบอีกคนหนึ่งเขียนแบบ ทั้งหมดที่จะพูดว่าฉันใช้ผิด / เข้าใจผิดกระบวนการสร้าง / บูรณาการอย่างต่อเนื่องหรือไม่ สำหรับฉันแล้วดูเหมือนว่า "ผ่าน" / "ไม่ผ่าน" เป็นตัวบ่งชี้ที่แคบเกินไป มีวิธีที่จะทำให้การรวมระบบอย่างต่อเนื่องและเข้ากันได้กับ TDD หรือไม่? อาจมีวิธีแก้ปัญหามาตรฐาน / การปฏิบัติเพื่อแยก "การทดสอบใหม่" (ที่สามารถล้มเหลว) และ "การทดสอบการถดถอย" (ที่ไม่ควรล้มเหลวเพราะพวกเขาเคยทำงาน)?

14 tdd  continuous-integration  tests 

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

14 testing  api  rest  continuous-integration  integration-tests 

ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน5 ปีที่ผ่านมา ฉันพบตารางเปรียบเทียบที่ยอดเยี่ยมนี้สำหรับเซิร์ฟเวอร์การรวมใน Wikipedia แต่ฉันไม่แน่ใจเล็กน้อยว่าจะจัดอันดับเครื่องมืออย่างไรกับความต้องการและความสนใจของฉัน แผนภูมิเองดูเหมือนว่าจะมีกล่องจำนวนมากที่ไม่รู้จักดังนั้นถ้าคุณสามารถอัปเดตใน Wikipedia ได้ก็สามารถทำได้เช่นกัน มีผลิตภัณฑ์ที่มีประสิทธิภาพสูงสุดสองสามอย่างหรือไม่ดังนั้นฉันจึงสามารถ จำกัด ตัวเลือกสี่หรือห้าตัวได้อย่างรวดเร็ว? ผลิตภัณฑ์ใดที่ดูเหมือนจะมีชุมชนผู้ใช้ที่ใหญ่ที่สุดและการปรับปรุงอย่างต่อเนื่องและการรวมเข้ากับเครื่องมือใหม่ ข้อเสนอโอเพ่นซอร์สนั้นดีที่สุดหรือมีเครื่องมือคุณภาพสูงที่สามารถจัดการได้อย่างยอดเยี่ยมสำหรับผู้ใช้คนเดียวที่บ้าน? การใช้ระบบหลายระบบ (เดสก์ท็อปหลักเซิร์ฟเวอร์เครือข่ายในบ้านเท่านั้นภายในเครื่องสมุดบันทึกส่วนตัวและที่ทำงานเครื่องเสมือนหลายเครื่องกระจายอยู่ทั่วทุกแห่ง) จะสร้างปัญหาและวิธีการจัดการได้อย่างไร

14 open-source  continuous-integration  build-system 

ควรบังคับใช้มาตรฐาน / รูปแบบการเข้ารหัสโดยเซิร์ฟเวอร์รวมอย่างต่อเนื่องที่ใช้เครื่องมือวิเคราะห์แบบคงที่ (เช่น PMD, StyleCop / FxCop) และการสร้างล้มเหลวหากไม่ปฏิบัติตามมาตรฐาน? กฎประเภทใดที่ไม่ควรใช้ในการสร้างล้มเหลว

14 coding-style  coding-standards  continuous-integration 

เราเป็น บริษัท เล็ก ๆ ที่มีหลายทีมที่จัดการที่เก็บคอมไพล์ของตัวเอง นี่คือแพลตฟอร์มเว็บและสิ่งประดิษฐ์ของแต่ละทีมจะถูกนำไปใช้ในตอนท้ายของวันสำหรับการทดสอบทุกคืน เรากำลังพยายามทำให้เป็นทางการกระบวนการเกี่ยวกับการกำหนดรุ่นและบรรจุภัณฑ์ ทุกทีมมีสาขาหลักที่พวกเขาทำการพัฒนาแบบวันต่อวัน สมาชิกการประกันคุณภาพของแต่ละทีมต้องการให้สิ่งประดิษฐ์จากการเปลี่ยนแปลงของทีมของพวกเขาถูกนำไปใช้ในห้องทดสอบที่มีการรวมส่วนประกอบทั้งหมดโดยเชฟ Artifacts เป็น tarballs แต่ฉันต้องการแปลงเป็น RPMs เพื่อให้เราสามารถคิดและเหตุผลเกี่ยวกับเวอร์ชันได้อย่างถูกต้อง กระบวนการปล่อยเกี่ยวข้องกับการตัดสาขาที่วางจำหน่ายจากสาขาการพัฒนา (ต้นแบบในกรณีส่วนใหญ่) ของที่เก็บ git แต่ละอัน สิ่งนี้จะมอบให้กับการประกันคุณภาพที่เรียกใช้การทดสอบและลงชื่อออกในชุดของสิ่งประดิษฐ์ ตัวอย่างเช่นนี่เป็นที่เก็บคอมไพล์ทั่วไปที่มีสาขาย่อยที่เกี่ยวข้อง: 0-0-0-0-0-0-0-0-0-0 (master) | | 0 0 (rel-1) | 0 (rel-2) ฉันพยายามที่จะหารูปแบบของแพคเกจที่มาจากสาขาการพัฒนา เราไม่ต้องการติดแท็กสาขาหลักของแต่ละ repo และ จำกัด แท็กเพื่อปล่อยสาขาเท่านั้น แต่เราควรจะสามารถค้นหาแพ็คเกจที่ปรับใช้ในเครื่องทดสอบโดยใช้ซีแมนทิกส์ yum / rpm มาตรฐาน เวอร์ชันการพัฒนาจะมีลักษณะอย่างไรเมื่อสาขาหลักไม่มีแท็ก ฉันเข้าใจว่าgit describeสามารถให้การแสดงเวอร์ชั่นประกอบที่มีประโยชน์แก่ฉันได้ แต่ทำงานได้ดีเมื่อติดแท็กจุดปล่อยต่างๆในสาขา แก้ไข 1: เพื่อตอบสนองต่อคำตอบของ …

13 git  continuous-integration  versioning  release-management  packages 

ขออภัยเกี่ยวกับโพสต์ที่ยาวนานนี้ แต่ฉันคิดว่ามันคุ้มค่า ฉันเพิ่งเริ่มต้นด้วยร้าน. NET ขนาดเล็กที่ทำงานค่อนข้างแตกต่างจากที่อื่น ๆ ที่ฉันเคยทำงาน ซอฟท์แวร์ที่เขียนตรงนี้ไม่ได้อยู่ในตำแหน่งก่อนหน้าใด ๆ ของฉันตรงที่มีลูกค้าหลายรายและไม่ใช่ลูกค้าทุกคนที่จะได้รับซอฟต์แวร์รุ่นล่าสุดพร้อมกัน ด้วยเหตุนี้จึงไม่มี "เวอร์ชันการผลิตปัจจุบัน" เมื่อลูกค้าได้รับการอัปเดตพวกเขายังได้รับคุณสมบัติทั้งหมดที่เพิ่มเข้ามาในซอฟต์แวร์ตั้งแต่การอัปเดตครั้งล่าสุดซึ่งอาจเป็นเวลานานแล้ว ซอฟต์แวร์สามารถกำหนดค่าได้อย่างมากและสามารถเปิดและปิดคุณสมบัติ: เรียกว่า "สลับคุณสมบัติ" วัฏจักรการวางจำหน่ายของที่นี่แน่นมากจริงๆแล้วมันไม่ได้อยู่ในกำหนดเวลา: เมื่อคุณสมบัติเสร็จสมบูรณ์ซอฟต์แวร์จะถูกปรับใช้กับลูกค้าที่เกี่ยวข้อง ทีมเมื่อปีที่แล้วย้ายจาก Visual Source Safe ไปยัง Team Foundation Server ปัญหาคือพวกเขายังคงใช้ TFS ราวกับว่ามันเป็น VSS และบังคับใช้ Checkout ล็อคในสาขารหัสเดียว เมื่อใดก็ตามที่การแก้ไขข้อผิดพลาดถูกนำออกสู่สนาม (แม้กระทั่งสำหรับลูกค้าเดี่ยว) พวกเขาเพียงแค่สร้างสิ่งที่อยู่ใน TFS ทดสอบข้อผิดพลาดได้รับการแก้ไขและปรับใช้ให้กับลูกค้า! (ตัวเองมาจากพื้นหลังของซอฟต์แวร์ยาและอุปกรณ์การแพทย์ซึ่งไม่น่าเชื่อเลย!) ผลที่ได้คือรหัส dev ที่อบออกมาครึ่งหนึ่งถูกนำไปผลิตโดยไม่ต้องมีการทดสอบ บั๊กมักจะลื่นไถลไปสู่รุ่นวางจำหน่าย แต่บ่อยครั้งที่ลูกค้าที่เพิ่งได้รับบิลด์จะไม่เห็นบั๊กเหล่านี้หากพวกเขาไม่ได้ใช้คุณสมบัติที่บั๊กนั้นอยู่ผู้อำนวยการรู้ว่านี่เป็นปัญหาเพราะ บริษัท เริ่มเติบโต ทันใดนั้นมีลูกค้ารายใหญ่บางรายเข้ามาและมีลูกค้าจำนวนน้อยกว่า ฉันถูกขอให้ดูที่ตัวเลือกการควบคุมแหล่งที่มาเพื่อกำจัดการปรับใช้ buggy หรือรหัสที่ยังไม่เสร็จ …

13 svn  continuous-integration  team-foundation-server 

วิธีแก้ปัญหาทั่วไปคือการสร้าง CI (การรวมอย่างต่อเนื่อง) ที่ทำงานบนบิลด์เซิร์ฟเวอร์: มันจะวิเคราะห์ซอร์สโค้ด, สร้างบิลด์ (ในการดีบัก) และรันการทดสอบ, ครอบคลุมการทดสอบวัด ฯลฯ ตอนนี้ชนิดบิลด์อื่นที่มักรู้จักกันคือ "บิลลี่ยามค่ำคืน": ทำสิ่งที่ช้าเช่นสร้างเอกสารรหัสสร้างแพ็คเกจการติดตั้งปรับใช้กับสภาพแวดล้อมการทดสอบและทำการทดสอบอัตโนมัติ (ควันหรือยอมรับ) กับสภาพแวดล้อมการทดสอบเป็นต้น ตอนนี้คำถาม: จะดีกว่าไหมถ้ามี "build build" แยกกันเป็นสามเป็น build build? หรือ "Nightly build" ในโหมด release และใช้เป็นรีลีส? คุณใช้อะไรใน บริษัท ของคุณ (บิลด์รีลีสควรเพิ่มแท็กบางชนิดให้กับแหล่งควบคุมของเวอร์ชันผลิตภัณฑ์ที่มีศักยภาพ)

13 builds  release  continuous-integration 

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

12 continuous-integration  continuous-delivery 

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

12 git  continuous-integration  gitlab