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

ที่ บริษัท ของฉันเรามีปัญหาของงาน cron ที่แตกต่างกัน (ในหลาย ๆ ระบบ) และเริ่มกระบวนการด้วยตนเองซึ่งทำให้การทำงานทางธุรกิจของเราเป็นผลมาจากการพัฒนาที่รวดเร็วและการละเลยในเวลาต่อมา สักวันเราจะต้องหาวิธีแก้ปัญหาแบบรวมศูนย์ด้วยเหตุผลที่ชัดเจน ความคิดหนึ่งที่เราได้เริ่มต้นกันคือการใช้ซอฟต์แวร์การรวมอย่างต่อเนื่องของเรา (เจนกินส์) เพื่อเรียกใช้กระบวนการเหล่านี้ซึ่งดูเหมือนว่ามีเหตุผล คำถามของฉันคือ: บริษัท อื่น ๆ กำลังทำเช่นนี้หรือไม่? นี่เป็นวิธีปฏิบัติที่ยอมรับกันโดยทั่วไปหรือไม่ สิ่งนี้ขัดแย้งกับคำจำกัดความของเครื่องมือ CI โดยนัยในชื่อหรือไม่? มีตัวเลือกอื่น ๆ อีกไหม? หมายเหตุ: https://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins เจนกินส์อ้างว่ามันมุ่งเน้นไปที่ "การตรวจสอบการดำเนินการของงานที่ดำเนินการจากภายนอกเช่นงาน cron และงาน procmail" ฉันไม่แน่ใจว่านี่เป็นสิ่งที่ฉันกำลังพูดถึงหรือไม่

29 continuous-integration  cron 

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

25 version-control  teamwork  continuous-integration  builds  branching 

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน5 ปีที่ผ่านมา ฉันเข้าใจแนวคิดพื้นฐานของ Git / Github ส่วนใหญ่แล้วในตอนนี้อย่างไรก็ตามฉันยังคงมีปัญหาในการเข้าใจภาพรวมที่ใหญ่ขึ้น นี่คือบางสิ่งที่ฉันสามารถทำให้ทำงานได้จนถึงตอนนี้: ผลักดันมุ่งมั่น ทำงานกับสาขา รวม Github กับ Travis CI ซึ่งเป็นระบบการรวมอย่างต่อเนื่อง Via Travis CI สร้างโดยอัตโนมัติทุกคอมมิทถึงมาสเตอร์และวางจำหน่ายเป็น ZIP บน Github ภายใต้รีลีส อย่างไรก็ตามฉันเพิ่งทำงานกับโปรเจ็กต์เวอร์ชันอัลฟ่า / เบต้าเท่านั้นดังนั้นฉันจึงไม่เคยเห็นเวอร์ชันที่เผยแพร่ในทางปฏิบัติเลย ดังนั้นฉันต้องการเรียนรู้เพิ่มเติมเกี่ยวกับการกำหนดรุ่นการบำรุงรักษารุ่นแยกต่างหากการแก้ไขด่วนรุ่น ฯลฯ ฉันจะมั่นใจได้อย่างไรว่าสิ่งต่าง ๆ ต่อไปนี้เกิดขึ้น: มีเวอร์ชันของโครงการต่าง ๆ ของฉันเช่นเวอร์ชัน 1.1.0 และ 2.0.0 มีความสามารถในการผลักดันโปรแกรมแก้ไขด่วนในรุ่นเรียงลำดับของกระแทกกับรุ่น 1.1.1 หรือ 2.0.1 เป็นต้น สร้างระบบการรวมอย่างต่อเนื่องสร้างรุ่นนั้นโดยอัตโนมัติเมื่อกระทำและหากสำเร็จให้เผยแพร่รุ่นสำหรับรุ่นนั้นโดยเฉพาะ ฉันสงสัยระหว่างตัวเลือกต่อไปนี้: …

24 version-control  git  github  continuous-integration 

ฉันไม่เคยใช้ระบบการรวมต่อเนื่อง (CI) มาก่อน ฉันใช้รหัสเป็นหลักใน MATLAB, Python หรือ PHP ทั้งสองอย่างนี้มีขั้นตอนการสร้างและฉันไม่เห็นว่าจะใช้ CI สำหรับงานของฉันได้อย่างไร เพื่อนในโครงการขนาดใหญ่ใน บริษัท ขนาดใหญ่บอกฉันว่าภาษาไม่สำคัญ ฉันไม่เห็นว่า CI จะเป็นประโยชน์กับฉันอย่างไรหากฉันไม่มีขั้นตอนการสร้าง ฉันคิดว่า CI เป็นสภาพแวดล้อมการทดสอบที่จะเรียกใช้การทดสอบหน่วย ฉันพลาดอะไรไปรึเปล่า?

23 unit-testing  continuous-integration  integration-tests  build-system 

ฉันไม่ใช่วิศวกรซอฟต์แวร์ ฉันเป็นนักเรียนปริญญาเอกในสาขาธรณีศาสตร์ เกือบสองปีที่แล้วฉันเริ่มเขียนโปรแกรมซอฟต์แวร์เชิงวิทยาศาสตร์ ฉันไม่เคยใช้การรวมอย่างต่อเนื่อง (CI) ส่วนใหญ่เป็นเพราะในตอนแรกฉันไม่รู้ว่ามันมีอยู่จริงและฉันเป็นคนเดียวที่ทำงานกับซอฟต์แวร์นี้ ในขณะนี้เนื่องจากฐานของซอฟต์แวร์กำลังเรียกใช้คนอื่นเริ่มสนใจและต้องการมีส่วนร่วมกับซอฟต์แวร์ แผนดังกล่าวคือบุคคลอื่น ๆ ในมหาวิทยาลัยอื่นกำลังนำส่วนเพิ่มเติมไปใช้กับซอฟต์แวร์หลัก (ฉันกลัวว่าพวกเขาสามารถแนะนำข้อบกพร่อง) นอกจากนี้ซอฟต์แวร์นั้นค่อนข้างซับซ้อนและยากที่จะทดสอบและฉันก็วางแผนที่จะทำงานต่อไป ด้วยเหตุผลสองประการนี้ฉันจึงคิดจะใช้ CI มากขึ้นเรื่อย ๆ เนื่องจากฉันไม่เคยมีการศึกษาวิศวกรซอฟต์แวร์และไม่มีใครรอบตัวฉันเคยได้ยินเกี่ยวกับ CI (เราเป็นนักวิทยาศาสตร์ไม่มีโปรแกรมเมอร์) ฉันพบว่ามันยากที่จะเริ่มต้นสำหรับโครงการของฉัน ฉันมีคำถามสองสามข้อที่ฉันต้องการคำแนะนำ: ก่อนอื่นคำอธิบายสั้น ๆ เกี่ยวกับการทำงานของซอฟต์แวร์: ซอฟต์แวร์ถูกควบคุมโดยไฟล์. xml ไฟล์เดียวที่มีการตั้งค่าที่จำเป็นทั้งหมด คุณเริ่มซอฟต์แวร์โดยเพียงแค่ส่งพา ธ ไปยังไฟล์. xml เป็นอาร์กิวเมนต์อินพุตและรันและสร้างไฟล์สองสามไฟล์ที่มีผลลัพธ์ การวิ่งครั้งเดียวสามารถใช้เวลา ~ 30 วินาที มันเป็นซอฟต์แวร์ทางวิทยาศาสตร์ ฟังก์ชั่นเกือบทั้งหมดมีพารามิเตอร์อินพุตหลายค่าซึ่งชนิดส่วนใหญ่เป็นคลาสที่ค่อนข้างซับซ้อน ฉันมีไฟล์. txt หลายไฟล์ที่มีแค็ตตาล็อกขนาดใหญ่ซึ่งใช้สร้างอินสแตนซ์ของคลาสเหล่านี้ ตอนนี้มาคำถามของฉัน: การทดสอบหน่วยการทดสอบบูรณาการการทดสอบแบบครบวงจร? : ซอฟต์แวร์ของฉันมีโค้ดประมาณ 30,000 บรรทัดพร้อมฟังก์ชั่นนับร้อยและ ~ 80 คลาส …

22 object-oriented  c++  testing  continuous-integration 

เวอร์ชันผลิตภัณฑ์เช่นv1.0.0.100ไม่เพียงแสดงถึงการผลิตซอฟต์แวร์ที่ไม่ซ้ำใคร แต่ช่วยระบุชุดคุณลักษณะและขั้นตอนการแก้ไขด่วนสำหรับผลิตภัณฑ์ดังกล่าว ตอนนี้ฉันเห็นสองวิธีในการรักษาแพ็กเกจ / build / ไบนารีเวอร์ชันสุดท้ายของผลิตภัณฑ์: การควบคุมเวอร์ชัน ไฟล์ที่เก็บหมายเลขรุ่น เซิร์ฟเวอร์การสร้างการรวมต่อเนื่อง (CI) จะมีสคริปต์เพื่อสร้างซอฟต์แวร์ที่ใช้หมายเลขรุ่นที่เช็คอินนี้เพื่อใช้กับทุกพื้นที่ของซอฟต์แวร์ที่ต้องการ (ไบนารีแพคเกจการติดตั้งหน้าช่วยเหลือเอกสาร ฯลฯ ) สภาพแวดล้อมและ / หรือสร้างพารามิเตอร์ สิ่งเหล่านี้ได้รับการดูแลรักษาไว้นอกการควบคุมเวอร์ชัน (เช่นไม่ได้เชื่อมโยงกับสแน็ปช็อต / แท็ก / สาขา) สคริปต์การสร้างกระจายและใช้หมายเลขในลักษณะเดียวกัน แต่พวกเขาเพิ่งได้รับค่าที่แตกต่างกัน (มันมีให้กับสคริปต์การสร้างแทนที่จะให้สคริปต์รู้ว่าจะรับได้ที่ไหนเทียบกับต้นไม้แหล่งที่มา) ปัญหาที่เกิดขึ้นกับวิธีแรกคือมันสามารถทำให้เกิดการผสมข้ามสาขาได้ยาก หากคุณยังคงรักษาซอฟต์แวร์รุ่นเดียวกันไว้ 2 ขนานคุณจะแก้ไขข้อขัดแย้งเมื่อรวมระหว่างการฉีดสองครั้งหากเวอร์ชันมีการเปลี่ยนแปลงทั้งคู่ตั้งแต่การรวมครั้งล่าสุด ปัญหาเกี่ยวกับวิธีการที่สองคือการกระทบยอด เมื่อคุณกลับไปที่การวางจำหน่าย 1 ปีที่ผ่านมาคุณจะพึ่งพาข้อมูลแท็กเพียงอย่างเดียวเพื่อระบุหมายเลขรุ่น ในทั้งสองกรณีอาจมีบางแง่มุมของหมายเลขเวอร์ชันที่ไม่ทราบก่อนสร้าง CI ตัวอย่างเช่นการสร้าง CI โดยทางโปรแกรมอาจใส่องค์ประกอบที่ 4 ซึ่งเป็นหมายเลขบิลด์อัตโนมัติ (เช่นบิลด์ที่ 140 ในสาขา) อาจเป็นหมายเลขการแก้ไขใน VCS วิธีที่ดีที่สุดในการติดตามหมายเลขเวอร์ชันของซอฟต์แวร์คืออะไร ควรรักษาชิ้นส่วน "รู้จัก" …

22 version-control  continuous-integration  versioning  release-management  continuous-delivery 

คำถามนี้ถูกโยกย้ายจาก Stack Overflow เพราะสามารถตอบได้ใน Software Engineering Stack Exchange อพยพ 7 ปีที่ผ่านมา ในช่วงเวลาหลายปีของการเขียนโปรแกรม Java และ Scala เมื่อเร็ว ๆ นี้ฉันไม่เคยใช้ Ant, Maven, Gradle หรือเครื่องมือสร้างเหล่านี้สำหรับ Java ทุกที่ที่ฉันทำงานมีผู้จัดการสร้างที่ดูแลทุกอย่าง - ฉันรวบรวมภายในเครื่องด้วย IDE สำหรับการพัฒนาและทดสอบหน่วยจากนั้นตรวจสอบในซอร์สโค้ดและแจ้งผู้จัดการสร้างที่ทำสิ่งที่จำเป็น รวบรวมไฟล์ของทุกคนสำหรับสภาพแวดล้อมที่ใช้ร่วมกัน ตอนนี้ฉันอยู่ระหว่างสัญญาฉันได้ทำงานในโครงการที่ได้รับทุนของตัวเองแล้วและถึงจุดที่มันจะดีพอที่จะทำเงินได้จริง ฉันยังมีนักลงทุนที่คาดหวังและวางแผนที่จะแสดงให้พวกเขาเห็นเป็นรุ่นเบต้าในไม่กี่สัปดาห์ แต่ตลอดฉันคลิกปุ่มสร้างบน IDE และสร้างไฟล์ Jar และใช้งานได้ดี แน่นอนว่าภูมิปัญญาดั้งเดิมแสดงให้เห็นว่าฉัน "ควร" เขียนสคริปต์ Ant / Maven / Gradle ของตัวเองและใช้สิ่งนั้นแทน IDE แต่อะไรคือข้อดีที่เป็นรูปธรรมในสถานการณ์ของฉัน (ทำงานคนเดียว)? ฉันได้อ่านเกี่ยวกับวิธีการใช้เครื่องมือสร้างเหล่านั้นและดูเหมือนว่าฉันจะเขียน XML …

22 builds  continuous-integration  maven  ant 

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

22 continuous-integration  continuous-delivery 

หนึ่งในบทบาทของผมในทีมงานของฉันคือคนที่สร้าง ฉันรับผิดชอบในการดูแลรักษา / ปรับปรุงสคริปต์การสร้างของเราและทำให้แน่ใจว่าเรากำลังสร้าง 'ราบรื่น' บนเซิร์ฟเวอร์การรวมอย่างต่อเนื่อง ฉันมักจะไม่รังเกียจงานนี้ แต่บ่อยครั้งที่รู้สึกว่าฉันดูแลเซิร์ฟเวอร์ CI อยู่ตลอดเวลา งานนี้อาจสร้างความรำคาญในบางครั้งเพราะหากงานสร้างฉันต้องทิ้งเรื่องราวที่ฉันกำลังทำอยู่และตรวจสอบความล้มเหลวของงานสร้าง การสร้างความล้มเหลวเกิดขึ้นทุกวันในทีมของเรา บางครั้งผู้พัฒนาก็ไม่ได้สร้างแบบโลคัลก่อนที่จะส่งข้อมูลดังนั้นการทดสอบล้มเหลวบนเซิร์ฟเวอร์ CI ในสถานการณ์เช่นนี้ฉันต้องการไปยังผู้ที่มี 'ความมุ่งมั่นที่ไม่ดี' อย่างรวดเร็วเพื่อให้การสร้างไม่ได้พักนานเกินไป บางครั้ง (บ่อยครั้งมาก) มีเงื่อนไขแปลก ๆ อยู่บนเซิร์ฟเวอร์ CI ที่ต้องทำการดีบั๊ก ฉันรู้ว่าหลาย ๆ ทีมที่เป็นผู้ใหญ่ใช้การผสมผสานอย่างต่อเนื่อง แต่ไม่มีเนื้อหาสาระเกี่ยวกับแนวทางปฏิบัติที่ดี ปัญหาของฉันชี้ให้เห็นว่าการรวมกลุ่มอย่างต่อเนื่องของเราไม่ได้เป็นผู้ใหญ่มากหรือเป็นเพียงส่วนหนึ่งของงานหรือไม่ แนวทางปฏิบัติที่ดีในการปฏิบัติตามคืออะไร? อะไรคือลักษณะของการบูรณาการอย่างต่อเนื่องเป็นผู้ใหญ่ ? ปรับปรุง แทนที่จะตอบความคิดเห็นฉันจะทำการอัปเดตแทน เรามีคำสั่งเดียวที่เรียบง่ายที่ทำสิ่งที่เซิร์ฟเวอร์การสร้างจะทำเมื่อสร้างแอป มันจะรวบรวมเรียกใช้หน่วย / การรวมและการทดสอบตาม UI อย่างรวดเร็ว การอ่านคำตอบของทุกคนรู้สึกว่าเราอาจมีปัญหาสองอย่าง CI Server ไม่บ่นดังพอเมื่อการสร้างล้มเหลว นักพัฒนาไม่รู้สึกว่าเป็นความรับผิดชอบของทุกคนในการทำให้แน่ใจว่าการกระทำของพวกเขาประสบความสำเร็จ สิ่งที่ทำให้ทีมของฉันลำบากยิ่งขึ้นคือเรามีทีมขนาดใหญ่ (นักพัฒนามากกว่า 10 คน) และเรามีสมาชิกในทีมนอกชายฝั่งสองคนที่กระทำเมื่อเราไม่ได้ทำงาน …

22 builds  continuous-integration 

ฉันกำลังตรวจสอบเทคนิคและกลยุทธ์ในการปรับขนาดการทดสอบการรวมระบบที่เพิ่มขึ้นของเราในผลิตภัณฑ์ปัจจุบันของเราเพื่อให้พวกเขาสามารถ (เป็นมนุษย์) ยังคงเป็นส่วนหนึ่งของการพัฒนาของเราและกระบวนการ CI ที่การทดสอบการรวมกันกว่า 200 ครั้งเราได้ทำเครื่องหมาย 1 ชั่วโมงเพื่อทำการทดสอบเต็มรูปแบบ (บนเครื่องเดสก์ท็อป aa) และสิ่งนี้มีผลกระทบในทางลบต่อความสามารถของนักพัฒนาในการทนต่อการรันทั้งชุด ซึ่งส่งผลต่อแรงจูงใจที่จะต้องมีระเบียบวินัยในการสร้างให้ดี เรารวมการทดสอบ Scenrios สำคัญเท่านั้นด้านหน้าไปด้านหลังและเราใช้สภาพแวดล้อมที่สะท้อนการผลิตที่สร้างขึ้นตั้งแต่เริ่มการทดสอบแต่ละครั้ง เนื่องจากเวลาที่ใช้ในการรันจึงทำให้วนรอบการตอบกลับแย่มากและวงจรที่สิ้นเปลืองจำนวนมากรอให้เครื่องทำการทดสอบเสร็จสิ้นไม่ว่าการทดสอบจะเน้นไปที่ใด ไม่ต้องกังวลกับผลกระทบด้านลบที่มีราคาแพงกว่าต่อการไหลและความก้าวหน้าสติและความยั่งยืน เราคาดว่าจะมีการทดสอบการรวมเพิ่มเป็น 10 เท่าก่อนที่ผลิตภัณฑ์นี้จะเริ่มทำงานช้าลง (ไม่มีความคิดจริง ๆ แต่ก็ไม่รู้สึกเหมือนว่าเรากำลังเริ่มต้นในแง่ของคุณสมบัติเลย) เราต้องคาดหวังอย่างต่อเนื่องว่าจะมีการทดสอบการรวมสองสามร้อยหรือสองสามพันครั้งฉันคิดว่าในบางจุด เพื่อความชัดเจนในการพยายามป้องกันไม่ให้สิ่งนี้กลายเป็นการสนทนาเกี่ยวกับการทดสอบหน่วยกับการทดสอบการรวม (ซึ่งไม่ควรแลกเปลี่ยน) เรากำลังทำการทดสอบทั้งหน่วยด้วย TDD และการทดสอบการรวมในผลิตภัณฑ์นี้ ในความเป็นจริงเราทำการทดสอบการรวมที่เลเยอร์ต่าง ๆ ในสถาปัตยกรรมบริการที่เรามีซึ่งมันสมเหตุสมผลสำหรับเราเนื่องจากเราต้องตรวจสอบตำแหน่งที่เราแนะนำการเปลี่ยนแปลงที่ผิดพลาดเมื่อเปลี่ยนรูปแบบในสถาปัตยกรรมของเราไปยังพื้นที่อื่น ๆ ของ ระบบ. เล็กน้อยเกี่ยวกับสแต็คเทคโนโลยีของเรา ขณะนี้เรากำลังทดสอบสภาพแวดล้อมการจำลอง (CPU และหน่วยความจำมาก) เพื่อทำการทดสอบของเราตั้งแต่ต้นจนจบ ซึ่งประกอบด้วยบริการเว็บ Azure REST ซึ่งแสดงแบ็กเอนด์ noSql (ATS) เรากำลังจำลองสภาพแวดล้อมการผลิตของเราโดยทำงานใน Azure desktop …

21 testing  continuous-integration  integration 

ฉันเปิดตัวบิลด์ทุกครั้งหลังทำคอมมิชชัน แต่ในโปรเจ็กต์ใหม่นี้สถาปนิกเพิ่งขอให้ฉันเปลี่ยนความถี่เป็น "สร้างทุก ๆ 15 นาที" และฉันก็ไม่เข้าใจว่าทำไมจึงเป็นเหตุผลที่ดี การสร้างในแต่ละการกระทำ " ก่อนปิดรายละเอียดบางอย่าง: โครงการ Objective-C (iOS 5) 10 ผู้พัฒนา แต่ละบิลด์ใช้เวลาประมาณ 1 นาทีและรวมถึงการสร้างและทดสอบหน่วย เซิร์ฟเวอร์การรวมเป็น Mac Mini ดังนั้นพลังการประมวลผลจึงไม่เป็นปัญหาสำหรับที่นี่ เราใช้ Jenkins กับปลั๊กอิน XCode ข้อโต้แย้งของฉันคือถ้าคุณสร้างแต่ละการกระทำคุณสามารถเห็นได้ในขณะนี้สิ่งที่ผิดพลาดและแก้ไขข้อผิดพลาดของคุณโดยตรงโดยไม่ต้องรบกวน dev อื่น ๆ บ่อยเกินไป นอกจากนี้ผู้ทดสอบของเราก็ใส่ใจน้อยลงด้วยข้อผิดพลาด UT ด้วยวิธีนี้ ข้อโต้แย้งของเขาคือการที่ devs จะถูกน้ำท่วมโดยอีเมล "ข้อผิดพลาดในการสร้าง" (ซึ่งไม่เป็นความจริงอย่างสมบูรณ์เนื่องจากเจนกินส์สามารถกำหนดค่าให้ส่งอีเมลสำหรับการสร้างที่พังครั้งแรกเท่านั้น) และเมตริกนั้นไม่สามารถทำได้อย่างถูกต้องหากความถี่ ของงานสร้างสูงเกินไป ดังนั้นคุณคิดอย่างไรกับเรื่องนี้?

20 objective-c  continuous-integration  jenkins 

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

19 git  continuous-integration  branching  devops 

ฉันคิดว่าบทความนี้เป็นโมเดลการแยกสาขาที่ประสบความสำเร็จเป็นที่รู้จักกันดีในหมู่ผู้ใช้ DVCS ที่มีประสบการณ์ ฉันใช้hgเป็นส่วนใหญ่ แต่ฉันจะโต้แย้งการอภิปรายนี้เป็นสิ่งที่ดีสำหรับ DVCS ใด ๆ เวิร์กโฟลว์ปัจจุบันของเราคือผู้พัฒนาแต่ละคนลอกแบบต้นแบบธุรกรรมซื้อคืน เราเขียนโค้ดลงบน repo ในพื้นที่ของเราเองทำการทดสอบและถ้าทุกอย่างเข้ากันได้ดีกับมาสเตอร์ ดังนั้นเราจึงต้องการติดตั้งเซิร์ฟเวอร์ CI เช่น Jenkins และปรับปรุงขั้นตอนการทำงานของเราด้วยระบบการจัดเตรียมในอนาคต ส่วนจริง แบบจำลองดังกล่าวข้างต้นใช้งานได้ดี แต่กิ่งสามารถทำลาย CI ได้ สาขาฟีเจอร์ควรซิงค์กับจุดเริ่มต้น (ตามบทความมันจะเป็นdevelopmentสาขา) เพื่อทำให้ CI และการผสานราบรื่นใช่ไหม? Say Alice และ Bob กำลังทำงานกับคุณสมบัติสองอย่าง แต่อลิซเสร็จในวันรุ่งขึ้น คุณสมบัติของ Bob ใช้เวลาหนึ่งสัปดาห์ เมื่อถึงเวลาที่บ๊อบเสร็จสิ้นการเปลี่ยนแปลงของเขาล้าสมัย (อาจจะมีการปรับโครงสร้างใหม่ / เปลี่ยนชื่อคลาสบางส่วน) ทางออกหนึ่งคือนักพัฒนาทุกเช้าต้องดึงmaster/originเพื่อตรวจสอบว่ามีการเปลี่ยนแปลงหรือไม่ หากอลิซส่งมอบบ๊อบควรดึงและรวมเข้าไปในพื้นที่ทำงานของเขาเพื่อให้ฟีเจอร์สาขาของเขาทันสมัย นี่เป็นวิธีที่ดีหรือไม่? ควรสาขาเหล่านี้มีอยู่ใน repo หลัก (ไม่ใช่โคลนแบบโลคอลหรือไม่) ความหมายของนักพัฒนาทุกคนควรให้สิทธิพิเศษแก่ repo หลักใน …

18 git  continuous-integration  mercurial  dvcs  branching 

หากคุณกำลังทำโครงการเดี่ยว - คุณจะใช้เครื่องมือ CI เพื่อสร้างจากพื้นที่เก็บข้อมูลหรือไม่? ฉันใช้ Hudson และ Cruise Control ในสภาพแวดล้อมแบบทีมซึ่งเป็นสิ่งสำคัญในการสร้างทันทีที่ทุกคนตรวจสอบสิ่งใด ฉันคิดว่าคุณค่าของการควบคุมเวอร์ชันยังคงชัดเจน แต่ฉันต้องสร้างหลังจากคอมมิชชันทุกครั้งเพราะฉันเพิ่งจะสร้างบนเครื่องของฉันและไม่มีใครทำอะไร

18 version-control  continuous-integration  builds  solo-development 

ฉันได้รับการพัฒนาบนมืออาชีพของฉันทั้งหมดและรักการทำงานกับรหัส ฉันไม่พอใจผู้นำทีมที่มีความเชี่ยวชาญเพียงเล็กน้อยหรือไม่มีเลยเกี่ยวกับเทคโนโลยีเฉพาะและยังยืนยันในการใช้งานบางอย่าง ตอนนี้ฉันพบว่าตัวเองอยู่อีกด้านหนึ่งของกระจกมอง ฉันเป็นผู้นำในการพัฒนาลูกค้าอ้วนที่จะนำไปใช้ใน C # อย่างไรก็ตามความเชี่ยวชาญของฉันคือการสร้างเว็บแอปพลิเคชัน Java ในขณะที่ฉันรู้ว่าฉันสามารถใช้ประโยชน์จากรูปแบบการออกแบบและกระบวนทัศน์ OO ในภาษาใด ๆ ฉันก็หลงทางเมื่อพูดถึงมาตรฐานการเข้ารหัสเครื่องมือวงจรชีวิตโครงการและขั้นตอนการเผยแพร่ / แจกจ่าย ฉันไม่สงสัยเลยว่าฉันจะสามารถรับพื้นฐานได้ภายในหนึ่งหรือสองเดือน แต่มีประสบการณ์บางอย่างที่สามารถรวบรวมได้ด้วยเวลาเท่านั้น ฉันควรทำอย่างไรและฉันจะหลีกเลี่ยงการเป็นผู้นำโครงการที่ฉันเกลียดเมื่อฉันพัฒนาได้อย่างไร

17 project-management  coding-standards  continuous-integration