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

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

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

คำถาม: ทำไมเราควรมีสภาพแวดล้อมการพัฒนาการทดสอบและการผลิตแยกต่างหาก

ทำไมเราควรมีสภาพแวดล้อมการพัฒนาการทดสอบและการผลิตแยกต่างหาก

คุณมีกิจกรรมหลายอย่างเกิดขึ้นพร้อมกัน:

• การพัฒนา - ที่นักพัฒนาใช้รหัสทำผิดทดลอง ฯลฯ ...
• การทดสอบ - ที่การทดสอบทำงานด้วยตนเองหรือโดยอัตโนมัติและเนื่องจากความซับซ้อนสามารถใช้ทรัพยากรจำนวนมาก
• การผลิต - ที่สร้างมูลค่าสำหรับลูกค้าและ / หรือธุรกิจ

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

สิ่งที่ป้องกันไม่ให้ปัญหาเหล่านี้เกิดขึ้น?

สภาพแวดล้อมที่แยกจากกัน

แล้วคุณต้องการอะไร

คุณต้องการสภาพแวดล้อมที่แยกจากกัน

ที่จะนำมันอย่างเป็นทางการ

คุณต้องการสภาพแวดล้อมที่แยกจากกันด้วยเหตุผลดังต่อไปนี้:

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

สำหรับบริบทของคุณซึ่งเป็นแพลตฟอร์มเทคโนโลยีใหม่

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

ฉันได้ยินมาว่าแนวทางปฏิบัติที่ดีที่สุดคือการมีสภาพแวดล้อมการพัฒนาการทดสอบและการผลิตแยกจากกัน แต่ทำไมถึงเป็นเช่นนั้น

มันไม่ชัดเจนเลยในวันนี้

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

ทำไมเราควรมีสภาพแวดล้อมการพัฒนาการทดสอบและการผลิตแยกต่างหาก

• หากมีการทดสอบข้อมูลของคุณเห็นโดยผู้ใช้จะไม่ดีมาก
• หากการมีข้อมูลแยงของคุณที่ผู้พัฒนา / ผู้ทดสอบเห็นนั้นแย่มาก
• หากคุณไม่สามารถไว้วางใจนักพัฒนาของคุณที่จะไม่ทำลายสิ่งที่ไม่ดีและคุณไม่สามารถแก้ไขสถานการณ์นั้นได้อย่างรวดเร็ว
• หากคุณมี CI อัตโนมัติในสถานที่เช่นนั้นรหัสส่งเสริมนั้นง่ายและรวดเร็ว

โดยพื้นฐานแล้วถ้าค่าใช้จ่ายของการมีสภาพแวดล้อมที่มีค่าน้อยกว่าค่าใช้จ่ายของไม่ได้มีสภาพแวดล้อม

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

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

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

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

การมีอินสแตนซ์ของออราเคิลเพียงตัวเดียวเท่านั้นไม่ได้หมายความว่า "ไม่มีการแยกระหว่างสภาพแวดล้อมการทดสอบและการผลิตจริง"!

คุณเขียนในความคิดเห็น

ขณะนี้เราใช้สกีมาที่แตกต่างกันสำหรับโครงการต่างๆ

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

ดังนั้นคำถามจริงที่คุณต้องถามคือ:

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

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

นอกจากนี้หนึ่งอินสแตนซ์ / หนึ่งเซิร์ฟเวอร์จะหมายถึงทรัพยากรที่ใช้ร่วมกันระหว่าง dev, test และ production - การจัดการผู้ใช้ / สคีมาที่ใช้ร่วมกัน, พื้นที่ดิสก์ที่แบ่งใช้, CPU ที่แชร์, แบนด์วิธเครือข่ายที่ใช้ร่วมกัน รวมสิ่งนี้เข้ากับ"กฎของ abstractions ที่รั่วไหล"และจะเห็นได้ชัดว่าการใช้เพียงตัวอย่างเดียวจะมีความเสี่ยงที่จะเกิดผลข้างเคียงที่ไม่พึงประสงค์ระหว่างสภาพแวดล้อม dev, test และ prod

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

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

นักพัฒนาสามารถอัปเดตรหัสในการพัฒนา รหัสอาจใช้งานไม่ได้ - แอปพลิเคชั่นอาจไม่เริ่มทำงาน

นั่นไม่ได้ส่งผลกระทบต่อ QA ที่กำลังทดสอบการสร้างที่เสถียรล่าสุดในสภาพแวดล้อมของตนเอง

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

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

จะเกิดอะไรขึ้นถ้าคุณมีหลายรุ่น? บางทีคุณกำลังพัฒนารุ่น 2.0 แต่ยังต้องการการแก้ไขข้อบกพร่องในสาขาบำรุงรักษา 1.0 ตอนนี้คุณต้องการการพัฒนาที่หลากหลายและสภาพแวดล้อม QA เพื่อให้แน่ใจว่าคุณสามารถพัฒนาและทดสอบสาขาใดก็ได้เมื่อพบข้อบกพร่องที่สำคัญและต้องแก้ไขเมื่อวานนี้

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

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

มีกองกำลังและศัตรูที่แตกต่างกันมากมาย มีค่าใช้จ่ายในการมีเซิร์ฟเวอร์จำนวนมากและค่าใช้จ่ายเพียงอันเดียว ฉันคิดว่าคำถามนี้อาจจะไกลเกินกว่าฐานข้อมูล? ฉันอาจจะเข้าใจผิด แต่มันเกี่ยวข้องกับความเข้าใจผิดที่เป็นระบบซึ่งมีค่าใช้จ่ายของ tangibles เทียบกับบทคัดย่อ

โดยทั่วไปแล้วค่าใช้จ่ายที่ชัดเจนนั้นง่ายต่อการเข้าใจ

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

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

เราใช้สภาพแวดล้อมที่แตกต่างกันเพื่อเปลี่ยนแปลงสิ่งเล็กน้อย

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

เราใช้สภาพแวดล้อมเพื่อพิจารณาผลกระทบของการเปลี่ยนแปลง

เราใช้สภาพแวดล้อมเพื่อลดต้นทุนที่เกี่ยวข้องกับการเปลี่ยนแปลง

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

คุณไม่เคยมีทีมงานขนาดเล็กเกินไปที่จะปฏิบัติตามรูปแบบการปฏิบัติประหยัดประหยัดขยันและพิสูจน์กระบวนการ

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

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