เหตุผลง่าย ๆ ที่ดีสำหรับการมีหลายสภาพแวดล้อม

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

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

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

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

คำตอบ: เงิน

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

ถ้าเราทั้งคู่นั่งอยู่ในห้องเป็นเวลา 2 ชั่วโมงเราอาจมีหลายสิบเหตุผลที่ดีกว่าที่จะมีสภาพแวดล้อมที่หลากหลาย

นี่เป็นปัญหา: ถ้าเหตุผลที่ยังไม่ได้ขึ้นอยู่กับเงินแล้วไม่มีของพวกเขามีความสำคัญ

โปรแกรมเมอร์ไม่ได้รับการว่าจ้างให้ฉลาด พวกเขาไม่ได้รับการว่าจ้างให้สร้างสรรค์ พวกเขาจ้างเพื่อเพิ่มรายได้ - โดยการหารายได้หรือการออมเงิน หากคุณไม่ได้ทำอย่างใดอย่างหนึ่งคุณควรรวบรวมประวัติย่อของคุณ

เมื่อมองจากมุมมองนั้นคำตอบนั้นง่าย:

การมีสภาพแวดล้อมเพียงแห่งเดียวนั้นช่วยเพิ่มการหยุดทำงานของเราและส่งผลให้รายได้ที่สูญเสีย สภาพแวดล้อมที่หลากหลายช่วยให้เราสามารถปกป้องผลกำไรของเราได้โดยให้ผู้ใช้ของเรามีส่วนหน้าที่เชื่อถือได้และเชื่อถือได้เหมือน บริษัท ของเรา

ทำซ้ำทุกวัน

มีความคิดเห็นที่ดีด้านล่างที่เพิ่มคุณค่าที่แท้จริงให้กับคำตอบนี้ดังนั้นฉันจะพูดถึงพวกเขา:

• Karl Bielefeldt มีจุดที่ดีเมื่อเขากล่าวว่าการวิเคราะห์ต้นทุน / ผลประโยชน์เป็นปัจจัยสำคัญ นักเศรษฐศาสตร์อาจอ้างถึงว่ามันเป็นค่าเสียโอกาสในการตามสภาพแวดล้อมที่หลากหลาย ในขณะที่มันอาจจะน่าแปลกใจที่ได้ยินมีสถานการณ์ที่หลายสภาพแวดล้อมอาจไม่ได้คำตอบ! หากเว็บไซต์ของ บริษัท ของคุณมีจำนวนน้อยมากการหยุดทำงานที่ไม่คาดคิดอาจเป็นวิธีที่คุ้มค่ากว่าในการทำธุรกิจ สิ่งนี้ไม่ได้ดูเหมือนตำแหน่งที่คุณอยู่ แต่ก็คุ้มค่าที่จะกล่าวถึง

• BlairHippo มีจุดที่ดีที่คุณควรรู้สึกฟรีเพื่อทำให้ดูเหมือนเป็นหายนะ (และถ้าคุณสูญเสียข้อมูลของคุณมันเป็น!) ความรับผิดเป็นเครื่องมือที่ยอดเยี่ยมสำหรับการโน้มน้าวใจผู้จัดการ แต่ก็ยังด้วยเหตุผลเดียวกัน - คดีความมีราคาแพง หลีกเลี่ยงพวกเขาประหยัดเงิน

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

จุดเดียวของความล้มเหลว

โดยไม่มีการพัฒนาหรือจัดเตรียมสภาพแวดล้อมคุณมีSingle Point of Failureสำหรับแอ็พพลิเคชันดั้งเดิมเหล่านั้น ฝ่ายบริหารจะได้ยินคุณหากคุณอธิบายแอปพลิเคชันรุ่นเก่าในข้อกำหนดเหล่านั้น

คุณต้องสามารถส่งข้อความของคุณเป็นไบต์เสียงที่เหมาะสมกับพวกเขา นำ " โปรแกรมเมอร์ Speak " ออกจากการสนทนาและแทนที่ด้วย " Manager Speak " แกล้งทำเป็นว่าคุณมีลิฟท์นั่ง 30 วินาทีเพื่อให้ได้คะแนนของคุณ

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

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

มันสำคัญจริงๆหรือ

ฉันสามารถเข้าใจความต้องการที่จะใช้สภาพแวดล้อมที่แยกจากกัน คำถามที่ไม่ชัดเจนคือ:

จำเป็นอย่างยิ่งที่จะต้องย้ายระบบเดิมหรือไม่

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

โดยทั่วไปการตัดสินใจทางธุรกิจทั้งหมดจะขึ้นอยู่กับต้นทุน / ผลประโยชน์ที่รับรู้ ดังนั้นคำถามที่ธุรกิจน่าจะถามคือ:

ต้นทุนของระบบเพิ่มเติมและการลงทุนเพื่อการพัฒนาในแอปพลิเคชันแบบดั้งเดิมนั้นคุ้มค่ากับผลประโยชน์เมื่อเทียบกับการลงทุนแบบเดียวกันในโครงการ / ผลิตภัณฑ์อื่นหรือไม่?

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

การแยกสภาพแวดล้อม

ธุรกิจเหตุผลกับสภาพแวดล้อมที่แยกต่างหาก

• ลดความเสี่ยงในการเผยแพร่และแก้ไขข้อผิดพลาด พิสูจน์ด้วยตัวเลข ผลิตภัณฑ์มีกี่ครั้งที่ล้มเหลวและต้นทุนรายได้ของลูกค้าเนื่องจากการเปิดตัว / ข้อบกพร่องที่ไม่ดี
• ลดความเสี่ยงในการพัฒนา การบังเอิญ dev db ออกไปนั้นแตกต่างจากการพัด db การผลิตออกไปโดยไม่ได้ตั้งใจ
• ความสามารถในการแยกบทบาทและการเข้าถึงอย่างชัดเจนเช่น ความปลอดภัยที่ดีขึ้น การ จำกัด จำนวนนิ้วในการผลิตเป็นสิ่งที่ดี
• ความสามารถในการแยกสภาพแวดล้อมและวิธีปฏิบัติและขั้นตอนที่สอดคล้องกับรูปแบบการพัฒนานี้ช่วยให้สามารถสร้างระบบคลาวด์ในอนาคตได้
• การแยกของสภาพแวดล้อมควรบังคับประสิทธิภาพในการจำลองสภาพแวดล้อมซึ่งอาจเป็นประโยชน์ในกำหนดเวลาเช่นเดียวกับการปรับขนาดแบบไดนามิก

ดูเหมือนคุณจะมีข้อโต้แย้ง "ถูกต้อง" อยู่แล้ว แต่คุณกำลังประสบกับ "ปลาเฮอริ่งแดง" ถ้าคุณต้องการ หรือ "ไล่แครอท"

การจัดการไม่มีเวลาและความสนใจในการฟังฉันจนกว่าจะมีปัญหาที่สำคัญ

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

ในกรณีเช่นนี้การพูดจาโผงผางที่ดีจะไม่ทำให้สิ่งที่คุณกำลังบอกทิศทาง อาจเป็นการบาดเจ็บที่รุนแรง (ความล้มเหลวของผลิตภัณฑ์ปรากฏแก่ลูกค้าและเชื่อมโยงโดยตรงกับแนวทางปฏิบัติที่ไม่ดี) แต่ฉันแน่ใจว่ามีความเชี่ยวชาญด้านเทคโนโลยีที่ชาญฉลาดก่อนที่คุณจะลองพูดคุย

คำแนะนำของฉันคือการดูดขึ้นและนำสิ่งที่พวกเขาหรือมองหาตำแหน่งใหม่

กลุ่มคนจำนวนมากวางแผนที่จะทำงานกับแอพในแต่ละครั้ง? ตามปกติแล้วฉันเคยเห็นสภาพแวดล้อมเดียวสำหรับคนแต่ละกลุ่ม นี่คือนักพัฒนา (พวกเขาได้รับสภาพแวดล้อม DEV และสภาพแวดล้อม DEV Integration - บางคนบอกว่าไม่จำเป็น 100% ฉันจะบอกว่ามันแตกต่างกันไปตามโครงการ), สภาพแวดล้อมการทดสอบสองแบบ (กลุ่มผู้ทดสอบกลุ่มหนึ่งทำการทดสอบรายละเอียดมาก ผู้ทดสอบ QA ระดับสูง - โดยปกติแล้วพวกเขาจะเป็นผู้ใช้ทางธุรกิจจริงไม่ใช่ผู้ทดสอบที่ได้รับการฝึกฝนมา) นอกจากนี้ยังมีสภาพแวดล้อมการทดสอบประสิทธิภาพแบบแยกส่วน (เพื่อให้คุณสามารถทดสอบข้อมูลจำนวนมากจำลองผู้ใช้จำนวนมาก ฯลฯ ... g)

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

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

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

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

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

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

นี่คือหนึ่ง: testability

การมีสภาวะแวดล้อมการทดสอบให้อิสระแก่คุณในการทำการทดสอบบนฐานข้อมูลที่ไม่สามารถทำได้ในสภาพแวดล้อมการผลิต

คุณต้องการเปลี่ยนวิธีการที่องค์กรของคุณพัฒนาซอฟต์แวร์หรือไม่ ลืมความกังวลไปที่ "เหตุผล" สำหรับ "การทำสิ่งต่าง ๆ " มนุษย์จะไม่เปลี่ยนพฤติกรรมเพราะการโต้แย้งอย่างมีเหตุผล พวกเขาเปลี่ยนไปเพราะอิทธิพลทางจิตวิทยาต่อนิสัยของพวกเขา

ดังนั้นฉันจะไปกับสิ่งนี้ที่ไหน

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

• การสนับสนุนระดับรากหญ้า: ค้นหานักพัฒนา "มรดก" อีกคนหนึ่งที่ยินดีจะให้การถ่ายภาพแก่คุณ ร่วมงานกับเขาและเปลี่ยนวิธีการทำงานของสิ่งต่าง ๆ อย่าประกาศการเปลี่ยนแปลง เพียงทำการเปลี่ยนแปลง หากใครเคยถามคุณเกี่ยวกับเรื่องนี้แค่พูดว่า "ใช่แล้วนั่นคือสิ่งที่เราทำตอนนี้"

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

• ตำหนิคนที่เหมาะสมสำหรับความผิดพลาดของพวกเขา ครั้งต่อไปที่ข้อผิดพลาดของแอปรุ่นเก่าถูกนำมาใช้ในการผลิตเนื่องจากกลไกการปรับใช้ยุคหินของคุณชี้ให้เห็น ทำอย่างละเอียด ... ไม่อยู่ในอีเมล ครั้งต่อไปที่คุณอยู่ในการประชุมกับผู้จัดการเพียงแค่พูดถึงตัวอย่างของเหตุผลที่การปรับใช้นั้นเป็นปัญหา “ ใช่จำได้ไหมว่าพวกเราทะเลาะกันเมื่อวันศุกร์เพราะข้อผิดพลาดที่ Bob ตรวจสอบในการผลิตหรือไม่ใช่นั่นเป็นความพยายามอย่างมาก!”

• ทำให้ง่ายต่อการทำในวิธีที่ดีกว่า ดูที่ iphone เช่น มีปุ่มเดียวอยู่ (ดีสอง) มันง่ายมากที่จะเปิด ทำให้การใช้งานกับหลายสภาพแวดล้อมบ้างี่เง่าง่าย ทำให้ง่ายมากที่ผู้จัดการทุกคนสามารถทำได้!

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

เราทำ DEV -> QA -> PROD (บางครั้งขั้นตอนเหล่านั้นจะแบ่งเป็นชิ้นเล็ก ๆ ) ด้วยฮาร์ดแวร์ที่เหมือนกันด้านหลัง ข้อมูลการผลิตปัจจุบันถูกส่งจาก PROD ไปยัง QA เป็น DEV เสมอ

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

QA: เมื่อนักพัฒนาของคุณพึงพอใจกับการทดสอบหน่วยถึงเวลาที่กลุ่มทดสอบต้องจับตามอง พวกเขาเรียกใช้กรณีทดสอบการทดสอบประสิทธิภาพและค้นหาข้อบกพร่อง ข้อบกพร่อง / enchancements เหล่านั้นจะถูกป้อนกลับไปที่ DEV และวงจรจะดำเนินต่อไปจนกว่าทุกคนจะมีความสุข

แยง: เมื่อคุณมาถึงขั้นตอนนี้คุณควรแน่ใจว่ารหัสทำงานร่วมกับข้อมูลปัจจุบันและผู้ใช้กลุ่ม QA / ธุรกิจของคุณมีความสุขกับการใช้งาน หากคุณทำทุกอย่างถูกต้องคุณควรจะสามารถอัปเดตรหัสและใช้งานได้

ในทำนองเดียวกันคุณจะไม่ปล่อยผลิตภัณฑ์ที่ยังไม่ได้ทดสอบแก่ลูกค้าคุณไม่ควรปล่อยรหัสที่ยังไม่ทดลองไปยังสภาพแวดล้อมการผลิต

หาก บริษัท ไม่เต็มใจที่จะลงทุนเวลาในการทำอย่างถูกต้องพวกเขาจะจ่ายคืนค่าใช้จ่ายในการบำรุงรักษาฉุกเฉินและข้อผิดพลาด 10 เท่า

ตัวอย่างเล็ก ๆ : เรามี บริษัท หนึ่งที่ตัดสินใจเปลี่ยนแปลงรายงานในการผลิตด้วยตนเอง ไม่มีใครรู้ว่ามันเปลี่ยนไปจนกระทั่งเราเข้ามาแก้ไขปัญหาที่หลากหลายในหนึ่งหรือสองปีข้างหน้า

เมื่อเราชี้ให้เห็นความผิดปกติในรายงานใบหน้าของ CFO เป็นสีขาวปรากฎว่าพวกเขาสูญเสียประมาณ $ 250,000 ต่อไตรมาสเพราะมีคนทำการเปลี่ยนแปลงอย่างรวดเร็ว

เกิดขึ้นบ่อยขึ้นแล้วคุณคิดว่าถ้าคุณไม่สามารถที่จะทำอย่างถูกต้องแล้วอย่าทำมัน

ฝ่ายบริหารมีส่วนสำคัญเบื้องหลังความสำเร็จของ บริษัท ซอฟต์แวร์และผลิตภัณฑ์ซอฟต์แวร์ที่ต้องการสร้างสภาพแวดล้อมเหล่านี้ ลองยกตัวอย่างโครงการของคุณ หากซอฟต์แวร์ของคุณได้รับการพัฒนาในปริมาณมากดังนั้นหากคุณไม่ได้จัดการข้อกำหนดของโครงการการควบคุมกระบวนการทดสอบการสร้าง ฯลฯ นี่เป็นโอกาสของความล้มเหลว เพื่อให้การบริหารจัดการโครงการมีอยู่

ฉันค่อนข้างเห็นด้วยกับ @ Stargazer712 ว่าข้อความของคุณชี้ไปที่เรื่องการเงิน แต่ตรวจสอบข้อความต่อไปนี้ที่ฉันได้รับจากหนังสือของ Marc Hamilton เกี่ยวกับการพัฒนาซอฟต์แวร์: การสร้างระบบที่เชื่อถือได้ (Prentice Hall PTR, 1999, ISBN 0-13-081246- 3) หลังจากดูปัจจัยเหล่านี้ทั้งหมดแล้ว ความคิดเห็นของฉันเกี่ยวกับคำถามของคุณคือสภาพแวดล้อมเดียวไม่ได้ให้เงินออมแก่คุณมันจะทำให้กระบวนการระยะยาวเพื่อทำให้โครงการ / ซอฟต์แวร์สมบูรณ์ สภาพแวดล้อมแบบกระจายจะประหยัดเวลาและรายได้ตามที่ฉันได้เรียนรู้และเห็นจากประสบการณ์ของฉันว่าสิ่งที่เกิดขึ้นกับ บริษัท ซอฟต์แวร์เริ่มต้นที่ฉันได้เริ่มให้บริการของฉัน

มีบทความมากมายที่แสดงให้เห็นว่าสิ่งที่สำคัญสำหรับความสำเร็จให้ตรวจสอบสิ่งนี้จัดระเบียบเพื่อการพัฒนาซอฟต์แวร์ที่ประสบความสำเร็จ

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

นักพัฒนาซอฟต์แวร์ชุดใหญ่จะต้องดิ้นรนและในที่สุดก็ไม่สามารถบรรลุเป้าหมายได้หากพวกเขาต้องใช้เวลาทั้งหมดต่อสู้กับโครงสร้างองค์กรที่ไม่เหมาะสม

การเริ่มต้นซอฟต์แวร์จำนวนมากเริ่มต้นชีวิตด้วยนักพัฒนาไม่กี่คนที่ทำงานในโรงรถ ไม่จำเป็นต้องมีโครงสร้างองค์กรมากในประวัติ บริษัท แต่โครงสร้างองค์กรยังคงมีอยู่ ตัวอย่างเช่นในปี 1977 เมื่อ Bill Gates และ Paul Allen ได้ก่อตั้ง บริษัท ร่วมกับพวกเขาและตั้งชื่ออย่างเป็นทางการว่า Microsoft บริษัท มีโครงสร้างองค์กรที่น้อยที่สุด มีพนักงานน้อยกว่าโหลที่ทำงานที่สำนักงานแห่งแรกของ Microsoft ในอัลบูเคอร์คีมลรัฐนิวเม็กซิโกและทุกคนรู้ว่าใครเป็นผู้รับผิดชอบ ไม่จำเป็นต้องมีแผนผังองค์กรที่ซับซ้อนเพื่อพิจารณาโครงสร้างการรายงานของทุกคน ในเวลาเดียวกันพนักงานทุกคนรู้บทบาทของพวกเขาใน บริษัท และสิ่งที่พวกเขากำลังพยายามทำให้สำเร็จ เนื่องจากโครงสร้างองค์กรที่ต้องการสามารถสื่อสารระหว่างพนักงานแต่ละคนได้อย่างไม่เป็นทางการ

ลืมเวลาเงินการตรวจสอบคุณภาพ ... แล้วชื่อเสียงล่ะ

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

เมื่อเร็ว ๆ นี้ Uber ได้ส่งรหัสไปยัง GitHub ที่มีรหัสผ่านสำหรับสภาพแวดล้อมการทำงานแบบสดซึ่งอนุญาตให้ 'แฮกเกอร์' ดาวน์โหลดรายละเอียดลูกค้าทั้งหมดของพวกเขา Uber บอกว่ามันเป็นการฝ่าฝืนคนอื่นบอกว่า "อย่าเอากุญแจไปล็อคของคุณในที่สาธารณะถ้านักพัฒนาของพวกเขาทำงานในสภาพแวดล้อมแบบ dev พวกเขาอาจปล่อยกุญแจสู่สภาพแวดล้อม dev ของพวกเขาบน gitub ไม่เป็นอันตราย. การที่ผู้ผลิตได้รับการปล่อยตัวแสดงให้เห็นว่าแนวคิดในการปฏิบัติงาน dev ในสภาพแวดล้อมการผลิตนั้นแย่เพียงใด

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

ดูเหมือนว่าคุณจะต้องมีสภาพแวดล้อมที่แตกต่างกันมากมายและทำให้คนต้องเสียเวลาในการตั้งค่า "สภาพแวดล้อม"

คุณควรมี"สภาพแวดล้อม"ที่แตกต่างกันจำนวนน้อยที่สุดที่คุณสามารถหลีกเลี่ยงได้ แต่สามารถลอกเลียนแบบได้หลายชุดด้วยเหตุผลหลายประการตามที่คุณและ บริษัท ต้องการ (ใช้ "สภาพแวดล้อม" เพื่อกำหนดค่าระบบ)!

ความแตกต่างเพียงอย่างเดียวที่ดีที่สุดควรเป็น:

1. ขนาด (ขั้นต่ำแนะนำสนับสนุนที่ใหญ่ที่สุด / ทดสอบกับ);
2. การจัดเตรียมและการผลิตไม่มีเครื่องมือในการพัฒนา
3. การผลิตได้รับการปกป้องจากการเขียนทับข้อมูลโดยไม่ตั้งใจ
4. คุณสามารถโหลดตัวอย่างการทดสอบหรือ [anoymized] ข้อมูลลูกค้าเพื่อการพัฒนาหรือการจัดเตรียมเซิร์ฟเวอร์ได้อย่างง่ายดาย

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

แก้ไขภายหลัง: สิ่งนี้กระตุ้นให้ฉันหาเหตุผลเข้าร่วมประชุมการตั้งชื่อด้วยผลิตภัณฑ์เว็บของฉัน (ขอบคุณสำหรับคำถาม) ฉันได้ตัดสินใจเกี่ยวกับ "สภาพแวดล้อม" สี่แห่งโดยมีการทดสอบแยกระหว่าง qa (ระดับเดียวขั้นต่ำสำหรับการทดสอบการทำงานเท่านั้น) และการจัดเตรียม (สถาปัตยกรรมเดียวกับการผลิตสำหรับการทดสอบโหลด / ประสิทธิภาพ / ปริมาณ)

ข้อแตกต่างที่แท้จริงเพียงอย่างเดียวในการเตรียมใช้งานคือการผลิต / การเตรียมการติดตั้งฐานข้อมูลไปยังระบบที่แยกต่างหากซึ่งฉันควบคุมโดยที่กลุ่มของเซิร์ฟเวอร์ที่แตกต่างกันอยู่ qa / dev มีทั้งบทบาทของเว็บเซิร์ฟเวอร์และ db การทำโหลดบาลานซ์ทำได้โดย cloudflare

ฉันยังมีตัวแปร ENV_NO ซึ่งส่งผ่านไปยังระบบเพื่อให้ฉันสามารถเลือกตัวอย่าง "qa" หรือ "staging" ได้มากเท่าที่ฉันต้องการ

ดังนั้นในการตั้งค่าสภาพแวดล้อม qa ที่สองรวมถึงการสำรองข้อมูลล่าสุดของฉันจาก live คำสั่งจะเป็น:

git checkout desired-branch/commit for provisioning
ENV_NO=2 bin/provision create qa
# come back after a short lunch

git checkout desired-branch/commit
ENV_NO=2 bin/cap qa deploy
# a minute or two

ENV_NO=2 bin/cap qa db:upload db:restore
# longer than I want once there is a decade of data ("longer" coffee break to traverse a 5.3km ADSL link)

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

จะใช้วิธีการ "ไข่ทั้งหมดในตะกร้าที่แตกต่างกัน": มันมีการจัดเตรียมกับนายทะเบียนสถานที่ / DNS อื่นโฮสต์ DNS ผู้ให้บริการโฮสต์ระบบ นี่คือเครือข่ายความปลอดภัยขั้นสูงสุด / สุดท้ายดังนั้นหากทุกอย่างลุกเป็นไฟคุณอย่างน้อยก็สามารถเข้าถึงข้อมูลได้จนถึงคืนที่ผ่านมา สคริปต์การจัดสรรแยกความแตกต่างระหว่างผู้ให้บริการที่แตกต่างกันดังนั้น 99% จึงเหมือนกันเพียงแค่ตั้งค่าสถานะแบบอ่านอย่างเดียว ตัวโหลดบาลานซ์ของ Cloudflare จะเปลี่ยนเส้นทางการรับส่งข้อมูลไปยังไซต์แบบอ่านอย่างเดียวหากเซิร์ฟเวอร์ที่ใช้งานจริงทั้งหมดล้มเหลว

เมื่อพูดถึงการเปลี่ยนแปลงคุณจะโชคดีที่มีใครสักคนที่จะรับฟังความคิดเห็นมืออาชีพของคุณและดำเนินการเปลี่ยนแปลงตามที่แนะนำ

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

ReSharper มีค่าใช้จ่ายประมาณ 50 ต่อนักพัฒนา ต้นทุนนักพัฒนาโดยเฉลี่ยต่อปีคือ 40k ReSharper ควรเพิ่มประสิทธิภาพการพัฒนาโดยอย่างน้อย 20% เนื่องจากใช้อย่างเต็มประสิทธิภาพ สมมติว่านักพัฒนาใช้เวลา 75% ของเวลาในการเขียนโค้ดใน IDE 75% ของ 40k คือ£ 30k £ 30k ตอนนี้เป็นต้นทุนของการพัฒนา เปอร์เซ็นต์ผลผลิตเพิ่มเติม (1%) ต่อปีมีค่าใช้จ่าย£ 300 เพื่อให้ได้ผลผลิตเพิ่มขึ้น 20% ธุรกิจจะต้องใช้เงิน 6k ปอนด์

หากคุณต้องการนำมุมมองนี้ไปใช้กับธุรกิจคุณสามารถพูดได้ว่าคุณสามารถจ้างคนอื่นและรับผลตอบแทนเพิ่ม 20% สำหรับ 6k ปอนด์หรือคุณสามารถได้รับผลลัพธ์เดียวกันโดยใช้เงิน 50 ปอนด์สำหรับใบอนุญาต ReSharper เมื่อตัวเลขอยู่หน้าธุรกิจการตัดสินใจจะง่ายขึ้น

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

คุณสามารถขอให้นักพัฒนาเพื่อนของคุณติดตามชั่วโมงที่ใช้ไปในแต่ละสัปดาห์เกี่ยวกับการกำหนดค่าแอปพลิเคชันสำหรับการพัฒนาการปรับใช้ ฯลฯ ตัวอย่างเช่นเวลาของนักพัฒนาอาวุโสสิบชั่วโมงอาจมีค่าใช้จ่ายธุรกิจ 500 นั่นคือ 10 ชั่วโมงที่สามารถใช้ในการพัฒนาหรือสิ่งที่สำคัญกว่านั้น คุณรวบรวมตัวเลขเป็นระยะเวลาหนึ่งและจัดทำธุรกิจด้วยค่าใช้จ่ายรายปี

ฉันเกลียดการเมืองแบบนี้เป็นการส่วนตัว แต่เป็นเรื่องปกติและเราต้องอยู่กับมัน