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

30
เป็นเรื่องผิดปกติสำหรับ บริษัท ขนาดเล็ก (นักพัฒนา 15 คน) ที่จะไม่ใช้การควบคุมแหล่งที่มา / รุ่นที่จัดการหรือไม่ [ปิด]
ไม่ใช่คำถามทางเทคนิค แต่มีคำถามอื่น ๆ อีกมากมายเกี่ยวกับการควบคุมแหล่งที่มาและแนวปฏิบัติที่ดีที่สุด บริษัท ที่ฉันทำงานด้วย (ซึ่งจะไม่เปิดเผยชื่อ) ใช้เครือข่ายแชร์เพื่อโฮสต์ซอร์สโค้ดและโค้ดที่นำออกใช้ เป็นความรับผิดชอบของนักพัฒนาหรือผู้จัดการในการย้ายซอร์สโค้ดไปยังโฟลเดอร์ที่ถูกต้องด้วยตนเองโดยขึ้นอยู่กับว่ามันเปิดตัวแล้วหรือยังและเป็นเวอร์ชั่นอะไร เรามีสเปรดชีตหลายจุดที่เราบันทึกชื่อไฟล์และเวอร์ชันและสิ่งที่เปลี่ยนแปลงไปและบางทีมก็ใส่รายละเอียดของเวอร์ชันต่าง ๆ ไว้ที่ด้านบนของแต่ละไฟล์ แต่ละทีม (2-3 ทีม) ดูเหมือนจะทำสิ่งนี้แตกต่างกันภายใน บริษัท อย่างที่คุณสามารถจินตนาการได้มันเป็นระเบียบที่จัดระเบียบเพราะ "คนที่ใช่" รู้ว่าสิ่งของของพวกเขาอยู่ที่ไหน แต่เป็นระเบียบเพราะมันแตกต่างกันไป ฉันพยายามผลักดันการควบคุมแหล่งที่มาที่มีการจัดการมาระยะหนึ่งแล้ว แต่ดูเหมือนว่าฉันจะไม่ได้รับการสนับสนุนเพียงพอภายใน บริษัท ข้อโต้แย้งหลักของฉันคือ: ปัจจุบันเรามีช่องโหว่; ณ จุดใด ๆ ที่ใครบางคนอาจลืมที่จะทำหนึ่งในหลาย ๆ การกระทำที่เราต้องทำซึ่งอาจหมายถึงการจัดเก็บทั้งเวอร์ชันไม่ถูกต้อง อาจต้องใช้เวลาหลายชั่วโมงหรือหลายวันกว่าจะแยกรุ่นกลับมารวมกันหากจำเป็น เรากำลังพัฒนาคุณสมบัติใหม่พร้อมกับการแก้ไขข้อบกพร่องและมักจะต้องชะลอการปล่อยของหนึ่งหรืออื่น ๆ เพราะงานบางอย่างยังไม่เสร็จสมบูรณ์ เราต้องบังคับให้ลูกค้าใช้เวอร์ชันที่มีคุณสมบัติใหม่แม้ว่าพวกเขาต้องการแก้ไขบั๊กเพราะมีเพียงเวอร์ชันเดียวเท่านั้นที่พวกเรากำลังทำงานอยู่ เรากำลังประสบปัญหากับ Visual Studio เนื่องจากผู้พัฒนาหลายรายกำลังใช้โครงการเดียวกันในเวลาเดียวกัน (ไม่ใช่ไฟล์เดียวกัน แต่ยังคงทำให้เกิดปัญหา) มีนักพัฒนาเพียง 15 คน แต่เราทำทุกอย่างแตกต่างกัน มันจะดีกว่าไหมถ้ามีแนวทางแบบมาตรฐานทั่ว บริษัท ที่เราทุกคนต้องปฏิบัติตาม …

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

4
คุณจะวางไลบรารี่ต่าง ๆ ในการควบคุมเวอร์ชันได้อย่างไร? คุณใช้แท็กหรือไม่ หรือสาขา หรือวิธีอื่น
ฉันเพิ่งเริ่มวางโค้ดของฉันภายใต้การควบคุมเวอร์ชัน (ในแล็บที่ฉันทำงานอยู่ภายใต้ SVN และรหัสของฉันเองใน GitHub (เห็นได้ชัดกับ git) ก่อนที่จะใช้การควบคุมเวอร์ชันฉันเคยทำอะไรแบบนี้ ฉันมีโฟลเดอร์ชื่อห้องสมุดในหลาย ๆ โฟลเดอร์ที่มีหมายเลขเวอร์ชัน ทุกครั้งที่ฉันต้องการเริ่มทำงานกับเวอร์ชันที่ใหม่กว่าฉันจะทำสำเนาของเวอร์ชันล่าสุดเปลี่ยนชื่อเป็นเวอร์ชันใหม่และเริ่มนำไปใช้ อย่างไรก็ตามวิธีนี้ดูเหมือนจะซ้ำซ้อนเมื่อโฟลเดอร์อยู่ภายใต้การควบคุมเวอร์ชัน นอกเหนือจากความซ้ำซ้อนหากมีคนต้องการรับรุ่นล่าสุดพวกเขาจะดาวน์โหลดทุกรุ่นถ้าเขาเพียงแค่imports / clones ตอนนี้ฉันเห็นหลายวิธีในการทำเช่นนี้ด้วยการควบคุมเวอร์ชัน แต่เนื่องจากฉันใหม่สำหรับมันฉันไม่ทราบว่าจะบำรุงรักษาได้ดีกว่า วิธีที่ 1: ใช้แท็ก หากฉันเข้าใจแท็กอย่างถูกต้องคุณจะมีสาขาหลักของคุณคุณยอมรับการเปลี่ยนแปลงใด ๆ ที่คุณได้รับและแท็กด้วยเวอร์ชัน จากนั้นเมื่อคุณต้องการได้รับสำเนาที่ใช้งานได้คุณจะได้รับแท็กที่แน่นอน (ช่วยแก้ให้ด้วยนะถ้าฉันผิด) วิธีที่ 2: เวอร์ชันการแยกสาขา ในวิธีนี้สาขาหลักจะเป็นสาขาการพัฒนา ทุก ๆ ครั้งที่มีการสร้างเวอร์ชันที่เสถียร (สมมติว่าv1.2.0) คุณสร้างสาขาสำหรับเวอร์ชันนั้นและไม่ผูกมัด ด้วยวิธีนี้หากคุณต้องการดาวน์โหลดเวอร์ชันใดรุ่นหนึ่งคุณจะได้รับรหัสจากสาขานั้น แม้ว่าฉันจะบอกว่าคุณไม่เคยยอมทำ แต่ก็เป็นไปได้ที่จะแก้ไขข้อผิดพลาดและผูกมัดกับสาขาของรุ่นเก่าเพื่อให้รุ่นเก่าทำงานต่อไป ตัวอย่างเช่นหากรุ่นปัจจุบันคือv2.0แต่มีคนที่ต้องการใช้v1.2คุณสามารถรับสาขาอื่นจากv1.2คือv1.2.1และกระทำการแก้ไขข้อบกพร่องหรือเพียงแค่ทำให้รุ่นเดียวกันv1.2และเพียงแค่แก้ไขข้อผิดพลาด ดังนั้นกิ่งจะเป็นดังนี้: v1.2.1 v1.2.2 / / v1.0.0 v1.2.0--------- v2.0.0 / / / …

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

10
คุณจะอัพเดตเว็บไซต์สดด้วยการเปลี่ยนรหัสได้อย่างไร
ฉันรู้ว่านี่เป็นคำถามพื้นฐานมาก หากมีใครสามารถตลกฉันและบอกฉันว่าพวกเขาจะจัดการกับเรื่องนี้ฉันจะยิ่งใหญ่ ฉันตัดสินใจที่จะโพสต์สิ่งนี้เพราะฉันกำลังจะติดตั้ง SynchToy เพื่อแก้ไขปัญหาด้านล่างและฉันรู้สึกไม่เป็นมืออาชีพเล็กน้อยเมื่อใช้ "ของเล่น" แต่ฉันไม่คิดว่าจะดีไปกว่านี้ หลายครั้งที่ฉันพบว่าเมื่อฉันอยู่ในสถานการณ์นี้ฉันพลาดวิธีที่ชัดเจนในการทำสิ่งต่าง ๆ - มาจากการเป็นนักพัฒนาเพียงคนเดียวใน บริษัท แอปพลิเคชันเว็บ ASP.NET ที่พัฒนาบนคอมพิวเตอร์ของฉันในที่ทำงาน โซลูชันมี 2 โครงการ: เว็บไซต์ (ไฟล์) WebsiteLib (C # / dll) ใช้ที่เก็บ Git นำไปใช้งานบนเว็บเซิร์ฟเวอร์ GoGrid 2008R2 การใช้งาน: ทำการเปลี่ยนแปลงรหัส กดเพื่อ Git รีโมตเดสก์ท็อปไปยังเซิร์ฟเวอร์ ดึงจาก Git เขียนทับไฟล์สดด้วยการลาก / วางด้วย windows explorer ในขั้นตอนที่ 5 ฉันลบไฟล์ทั้งหมดออกจากรูทเว็บไซต์ .. นี่เป็นสิ่งที่ไม่ควรทำ นั่นเป็นเหตุผลที่ฉันกำลังจะติดตั้ง SynchToy ... …

5
ผู้ทดสอบควรอนุมัติการปล่อยหรือเพียงแค่รายงานการทดสอบ?
มันสมเหตุสมผลไหมที่จะมอบอำนาจการออกจากระบบให้แก่ผู้ทดสอบ? ควรมีทีมทดสอบ เพียงทดสอบคุณสมบัติปัญหา ฯลฯ และเพียงรายงานตามเกณฑ์การผ่าน / ไม่ผ่านปล่อยให้ผู้อื่นดำเนินการกับผลลัพธ์เหล่านั้นหรือ มีอำนาจในการระงับการเผยแพร่ตัวเองตามผลลัพธ์เหล่านั้นหรือไม่ กล่าวอีกนัยหนึ่งผู้ทดสอบควรจะต้องออกจากระบบจริงหรือไม่? ทีมทดสอบที่ฉันทำงานด้วยรู้สึกว่าพวกเขาทำและเรากำลังมีปัญหากับเรื่องนี้เพราะ "การทดสอบขอบเขตคืบคลาน" - การปฏิเสธการอนุมัติการปล่อยบางครั้งก็ขึ้นอยู่กับปัญหาที่ไม่ได้รับการแก้ไขอย่างชัดเจน

2
การกำหนดเวอร์ชันแบบ Semantic เมื่อแก้ไขข้อบกพร่องที่สำคัญ
ฉันกำลังจัดการห้องสมุดซึ่งมีจำนวนมากของการใช้งานของประชาชนและผมมีคำถามเกี่ยวกับความหมายเวอร์ชัน ฉันต้องการ refactor หนึ่งส่วนที่สำคัญพอสมควรของห้องสมุดซึ่งถูกนำไปใช้อย่างไม่ถูกต้อง - และถูกนำไปใช้อย่างไม่ถูกต้อง แต่การทำเช่นนี้จะหมายถึงการเปลี่ยนแปลง API สาธารณะซึ่งเป็นการตัดสินใจที่สำคัญ การเปลี่ยนแปลงที่ฉันต้องการทำให้หมุนรอบวิธีใช้ตัววนซ้ำ ขณะนี้ผู้ใช้ต้องทำสิ่งนี้: while ($element = $iterator->next()) { // ... } ซึ่งไม่ถูกต้องอย่างน้อยใน PHP พื้นเมืองอินเตอร์เฟซ Iterator ฉันต้องการแทนที่ด้วยสิ่งนี้: while ($iterator->valid()) { $element = $iterator->current(); // ... $iterator->next(); } ซึ่งคล้ายกับ: foreach ($iterator as $element) { // ... } หากคุณดูที่คู่มือของ Tom เกี่ยวกับการกำหนดเวอร์ชันแบบ semantic เขาระบุไว้อย่างชัดเจนว่าการเปลี่ยนแปลงใด ๆ กับ …

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

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

5
วิธีง่ายๆในการปรับปรุงคุณภาพการเผยแพร่ในสภาพแวดล้อม RAD
พื้นหลังเล็กน้อยที่นี่ - เราเป็นทีมเล็ก ๆ (จาก 5) ของนักพัฒนา RAD ที่รับผิดชอบการพัฒนาซอฟต์แวร์ภายใน บริษัท ที่ไม่ใช่ซอฟต์แวร์ขนาดใหญ่ "ซอฟต์แวร์ภายใน" แตกต่างจากแอพพลิเคชันเดสก์ท็อป. NET ที่ใช้เซิร์ฟเวอร์ MSSQL เป็นแบ็กเอนด์ไปยังสคริปต์ Python ที่ทำงานบนพื้นหลังไปยังเอกสารและแม่แบบ MS Word - สวนสัตว์ของเทคโนโลยี ทีมงานทั้งหมดประกอบด้วยผู้รอบรู้ทุกคนสามารถรับข้อกำหนดจากผู้ใช้รหัสมันทดสอบและปรับใช้ในการผลิต เมื่อซอฟแวร์ในการผลิตมันถูกดูแลโดยทีมอื่น แต่มันมักจะง่ายสำหรับเราที่จะเข้าไปแทรกแซงหากมีอะไรผิดพลาด ทุกอย่างฟังดูดี แต่มีปัญหา - การเป็นทีม RAD ที่เราต้องปล่อยออกมาบ่อยครั้งและไม่มีวันที่เราจะไม่ปล่อยรุ่นใหม่ของแอปพลิเคชั่นหนึ่งหรือสอง (หรืออาจเป็นสคริปต์เอกสารเวิร์ดที่ได้รับการปรับปรุง แอพคอนโซล C ++ ฯลฯ ) ในการผลิต เราทำการทดสอบการพัฒนาและเกี่ยวข้องกับผู้ใช้ปลายทางโดยให้พวกเขาเรียกใช้ซอฟต์แวร์ในสภาพแวดล้อมของเอือด ... ... แต่ข้อบกพร่องกำลังคืบคลานเข้าสู่การผลิตอยู่ดี ผู้ใช้เข้าใจว่าข้อบกพร่องเหล่านี้และความไม่แน่นอนเป็นครั้งคราวคือราคาที่พวกเขาจ่ายเพื่อให้ได้สิ่งที่พวกเขาต้องการได้อย่างรวดเร็ว แต่ในขณะเดียวกันก็ทำให้เราคิด - บางทีเราอาจปรับปรุงการพัฒนาของเราหรือแนวทางปฏิบัติเพื่อปรับปรุงเสถียรภาพของ ซอฟต์แวร์และลดจำนวนข้อบกพร่องที่เราแนะนำเมื่อเพิ่มฟังก์ชันการทำงานใหม่ สิ่งที่ดี - …

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

5
คุณจะจัดการเวอร์ชันในโครงการหลายด้านได้อย่างไร
ฉันรู้ว่ามันเป็นคำถามกว้าง ๆ ดังนั้นฉันจะพยายามเจาะจงให้มากที่สุดเท่าที่จะทำได้ คำถามนี้เป็นคำถาม "องค์กร" มากกว่าคำถามทางเทคนิค เรามีโครงการหลายด้านที่มีองค์ประกอบหลักเหล่านี้: เซิร์ฟเวอร์ที่โฮสต์ตรรกะทางธุรกิจหลัก (ตัวแบบข้อมูล) BackOffice สำหรับลูกค้าที่ใช้ตรรกะทางธุรกิจหลัก แอปพลิเคชัน API (REST) ​​ซึ่งใช้ตรรกะทางธุรกิจหลักเช่นกัน มีแอพสมาร์ทโฟน (iOS และ Android) โดยใช้แอปพลิเคชัน API มีแอปแท็บเล็ตอีกแอนดรอยด์ที่แตกต่างจากสมาร์ทโฟนที่ใช้แอปพลิเคชัน API เดียวกัน เร็ว ๆ นี้ฉันจะอยู่ในการผลิตกับลูกค้าที่ใช้งานอยู่ และเป็นโครงการใด ๆ ฉันจะต้องบำรุงรักษาส่วนประกอบต่าง ๆ ทั้งหมดในช่วงเวลา นั่นหมายความว่าสามารถอัปเกรดทั้งหมดต่อไปนี้: รหัสของตรรกะทางธุรกิจหลักในเซิร์ฟเวอร์ (ใช้โดย back-office, API และผลข้างเคียงจากแอปมือถือ) API เอง (ใช้ทั้งแอพสมาร์ทโฟนและแท็บเล็ต) แอพมือถือทั้งหมด (ผ่าน appstore / googleplay) แน่นอนส่วนฝั่งเซิร์ฟเวอร์ (รหัสตรรกะทางธุรกิจหลักและรหัส API) สามารถเปลี่ยนแปลงได้ทันทีด้วยตัวเอง …

3
กลยุทธ์แพคเกจและรุ่นในสภาพแวดล้อมที่เก็บหลาย
เราเป็น บริษัท เล็ก ๆ ที่มีหลายทีมที่จัดการที่เก็บคอมไพล์ของตัวเอง นี่คือแพลตฟอร์มเว็บและสิ่งประดิษฐ์ของแต่ละทีมจะถูกนำไปใช้ในตอนท้ายของวันสำหรับการทดสอบทุกคืน เรากำลังพยายามทำให้เป็นทางการกระบวนการเกี่ยวกับการกำหนดรุ่นและบรรจุภัณฑ์ ทุกทีมมีสาขาหลักที่พวกเขาทำการพัฒนาแบบวันต่อวัน สมาชิกการประกันคุณภาพของแต่ละทีมต้องการให้สิ่งประดิษฐ์จากการเปลี่ยนแปลงของทีมของพวกเขาถูกนำไปใช้ในห้องทดสอบที่มีการรวมส่วนประกอบทั้งหมดโดยเชฟ 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: เพื่อตอบสนองต่อคำตอบของ …

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

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

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