คำถามติดแท็ก release-management

ที่ บริษัท ของฉัน (การเริ่มต้นอุตสาหกรรมเว็บอายุ 3 ปี) เรามีปัญหาบ่อยครั้งกับทีมผลิตภัณฑ์ที่พูดว่า "aaaah นี่คือการแก้ไขวิกฤติตอนนี้!" (ไม่ใช่ทุกคนเหรอ?) สิ่งนี้มีผลกระทบต่อความสามารถในการผลิต (และขวัญกำลังใจ) ของเจ้าหน้าที่วิศวกรรมรวมอยู่ด้วยตนเอง ฝ่ายบริหารใช้เวลาคิดเกี่ยวกับวิธีลดความถี่ของการร้องขอในวันเดียวกันและเกิดขึ้นกับวิธีแก้ปัญหาที่เรากำลังจะออกวางจำหน่ายทุกสัปดาห์ (ก่อนหน้านี้เราได้ทำทุกสองสัปดาห์ซึ่งโดยปกติจะลดลงภายในสองสามวันหรือมากกว่านั้น) มีผู้พัฒนา 13 คนและผู้ทดสอบนอกชายฝั่ง 6 คน / 9 คน ทฤษฎีคือนักพัฒนาเพียง 4 คน (และผู้ทดสอบทั้งหมด) จะทำงานในรุ่นที่มีเลขคู่เว้นเสียแต่ว่าจะมีชิ้นงานที่ต้องใช้ความเชี่ยวชาญเฉพาะจากนักพัฒนาอื่น ๆ แต่ละรอบจะมีงาน dev สองวันและงาน QA สองวัน (บวก 1 วันของการกำหนดขอบเขต / triage / ... ) คำถามของฉันคือ: (a) มีใครบ้างที่เคยมีประสบการณ์กับวงจรการเปิดตัวนี้หรือไม่? (b) มีใครเคยได้ยินเรื่องความยาวของรอบการเปิดตัวนี้ถึงแม้จะพยายามบ้างไหม? (c) ถ้า (a) …

12 agile  quality  release-management 

ฉันเป็นนักพัฒนาซอฟต์แวร์ในทีมเปรียวขนาดใหญ่พอสมควร (เรามีนักพัฒนาแปดคนทำการเปลี่ยนแปลงที่เก็บรหัสเดียว) ทุกสองสัปดาห์เราจะผลักดันซอฟต์แวร์เวอร์ชันใหม่ให้ผลิต นี่คือขั้นตอนการทำงานปัจจุบันของเรา: เมื่อเริ่มงานใหม่นักพัฒนาจะสร้าง "ฟีเจอร์บรานช์" จากสาขาการพัฒนาหลัก (เราใช้คอมไพล์ ) และทำงานนอกสาขาใหม่นี้ เมื่อนักพัฒนาซอฟต์แวร์ทำงานเสร็จแล้วพวกเขาจะรวมสาขาฟีเจอร์ของพวกเขากลับเข้าไปในสาขาการพัฒนา ผู้พัฒนาผสานสาขาการพัฒนาเข้ากับสาขา QA บิลด์จะถูกทริกเกอร์จากสาขา QA ผลลัพธ์ของโครงสร้างนี้ถูกปรับใช้ในสภาพแวดล้อม QA ของเราเพื่อให้ผู้ทดสอบเริ่มการทดสอบ เป็นเรื่องปกติที่ผู้ทดสอบของเราจะพบปัญหาเกี่ยวกับคุณสมบัติใหม่เหล่านี้ซึ่งได้รวมเข้ากับสาขา QA ซึ่งหมายความว่าในเวลาใดก็ตามสภาพแวดล้อม QA อาจมีคุณสมบัติใหม่หลายประการ - บางส่วนผ่านการทดสอบและปราศจากข้อบกพร่องและบางส่วนเสีย สิ่งนี้ทำให้การปล่อยทำได้ยากเพราะหายากที่ QA build อยู่ในสถานะพร้อมใช้งานการผลิต เพื่อบรรเทาปัญหานี้เราได้พยายามเริ่มต้น "การหยุด QA" ซึ่งหมายความว่านักพัฒนาไม่รวมสาขาการพัฒนาของเราเข้ากับสาขา QA สองสามวันก่อนการเปิดตัว การแก้ไขข้อบกพร่องของสภาพแวดล้อม QA นั้นเกิดขึ้นโดยตรงกับสาขา QA และรวมเข้ากับสาขาการพัฒนา ในทางทฤษฎีสิ่งนี้ทำให้คุณสมบัติใหม่แตกออกจาก QA ในขณะที่ยังช่วยให้เราสามารถแก้ไขปัญหาที่มีอยู่แล้วใน QA ในขณะที่แนวคิด "QA freeze" ประสบความสำเร็จเพียงบางส่วน แต่ก็ยากที่จะประสานงานและผู้คนมักสับสนว่าพวกเขาได้รับอนุญาตให้รวมกับ QA …

12 agile  version-control  development-process  branching  release-management 

เริ่มต้นด้วยทีม dev ใหม่ในโครงการใหม่และเราต้องกำหนดกลยุทธ์การแบ่งสาขาสำหรับแหล่งเก็บข้อมูลของเรา ( เช่น Microsoft Team Foundation Server 2010 ) เราได้ทำการอภิปรายกันอย่างเหนียวแน่นว่าจะ ... ก . มีสาขาReleaseหนึ่งสาขาที่เราผลิตงานสร้างและจากนั้นLabelเมื่อมีบางอย่างออกวางจำหน่ายจริง หรือ ข . มีสาขาReleaseใหม่สำหรับแต่ละ Release ใหม่เข้าสู่การผลิต ( เช่นเวอร์ชัน 1, 2, 3, ฯลฯ ... ) ตัวเลือกAดูเหมือนจะตรงไปตรงมา แต่เราไม่แน่ใจว่าสิ่งนี้จะนำไปสู่ปัญหาในระยะยาวหรือไม่ ตัวเลือกBดูเหมือนว่าจะเป็นเพียงการสร้างกิ่งไม้ที่มีอายุยืนยาวจำนวนมากเพียงครั้งเดียว ไม่มีใครมีประสบการณ์อย่างใดอย่างหนึ่งที่สามารถช่วยเราตัดสินใจได้ โดยเฉพาะฉันกำลังมองหาว่าจุดปวดอยู่ที่ใดสำหรับทางเลือกหนึ่ง อย่าลังเลที่จะมอบประสบการณ์เฉพาะที่เกี่ยวข้องกับ TFS และ / หรือนัยต่อการจัดการที่วางจำหน่าย

11 version-control  team-foundation-server  release-management  branching 

เรามีแอพพลิเคชั่นและบริการบนเว็บมากมาย (ผลิตภัณฑ์สาธารณะบางผลิตภัณฑ์, ภายในและส่วนหนึ่งของ "แบ็กเอนด์" ส่วนตัว) ที่พึ่งพาซึ่งกันและกัน แต่ละองค์ประกอบเหล่านี้มี 4 สภาพแวดล้อม (กลุ่มของเซิร์ฟเวอร์ / โหนดที่ให้บริการตามวัตถุประสงค์เฉพาะ): ที่ไม่ใช่การผลิต DEV- สภาพแวดล้อมการพัฒนาแบบบูรณาการที่ CI สร้างการเปลี่ยนแปลงแบบพุช มีประโยชน์สำหรับวิศวกรในการแก้ปัญหาข้อบกพร่องที่หายากที่ไม่สามารถทำซ้ำได้ QA - แยก QA / สภาพแวดล้อมการทดสอบ DEMO - สภาพแวดล้อมของ UAT ที่เสถียรสำหรับผู้มีส่วนได้เสีย การผลิต LIVE - สภาพแวดล้อมสด / การผลิตของเรา รหัสโปรโมชั่ไป: LOCAL(เครื่องของนักพัฒนา) => DEV=> QA=> =>DEMOLIVE บอกว่าเรามีโปรแกรมที่เรียกว่าmyappที่มีการสนับสนุนจากบริการเว็บ RESTful เรียกว่าmywsที่ตัวเองได้รับการสนับสนุนโดย DB mydbที่เรียกว่า ขณะนี้เรามีสิ่งที่ผมจะเรียกว่า " บงการ " …

10 continuous-integration  release-management  dependency-management  environment 

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

10 release-management  software-distribution  p2p 

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

10 scrum  release-management