คำถามติดแท็ก builds

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

1
จะ จำกัด การเข้าถึงระบบไฟล์ใน Atlassian Bamboo ได้อย่างไร
เรามี Atlassian Bamboo ที่ทำงานบน Ubuntu เมื่อนักพัฒนาตั้งค่าการสร้างเขาหรือเธอมีความเป็นไปได้ที่จะเรียกใช้งานเชลล์สคริปต์ สิ่งนี้มีประโยชน์ในการรันคำสั่ง (กำหนดเอง) บนโค้ดเบสที่คุณกำลังสร้าง อย่างไรก็ตามสคริปต์ที่เรียกใช้ยังสามารถเข้าถึงระบบไฟล์นอกไดเรกทอรีงานได้ในไดเรกทอรีการทำงานของ Bamboo ( <Bamboo-home-dir>/xml-data/build-dir/JOB_KEY) ดังนั้น JOB_A ยังสามารถเข้าถึงไฟล์ของ cd ../JOB_BJOB_B: มีความเป็นไปได้ที่จะ จำกัด การเข้าถึงนี้หรือไม่? ป.ล. ฉันทราบถึงความจริงที่ว่าบิลด์ทำงานโดยเอเจนต์ (ท้องถิ่นหรือระยะไกล) ในแบมบูและคุณสามารถสร้างโปรเจ็กต์ที่แตกต่างกันโดยเอเจนต์ต่าง ๆ อย่างไรก็ตามหากโครงการสองโครงการสร้างขึ้นโดยตัวแทนเดียวกันโครงการสามารถเข้าถึงไฟล์ของกันและกันได้

2
หลักสูตร Crash ใน Dev for Ops?
ฉันเรียนที่ CompSci ที่ซึ่งเราสอน Java เป็นหลัก แต่สิ่งที่ฉันเรียนรู้คือความหลงใหลในระบบคืออะไรฉันจึงทำงานด้าน ops เสมอ ฉันมีประโยชน์กับการเขียนสคริปต์ดังนั้นฉันจึงไม่ได้มองหาเว็บไซต์ที่จะสอน Ruby ให้ฉัน แต่เป็นสิ่งที่จะอธิบายเพิ่มเติมในเชิงลึกเกี่ยวกับสิ่งที่คุณทำอยู่ทุกวัน ฉันต้องการเข้าใจวัฒนธรรมที่ดีขึ้นและวิธีที่คุณแยกแยะจำนวนไฟล์ที่แท้จริงในโครงการของคุณ - สิ่งที่จับต้องไม่ได้ ถ้าฉันเรียนรู้วันนี้ฉันถูกย้ายไปที่ทีมพัฒนาในวันจันทร์ฉันจะอ่านอะไรในสุดสัปดาห์นี้

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