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

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

สถาปัตยกรรมการปรับใช้มีความหลากหลายอย่างมาก แต่โดยทั่วไปแล้ว จะแบ่งระดับออกเป็นสองส่วน คือการพัฒนา (DEV) และการใช้งาน จริง (PROD) สถาปัตยกรรม 4 ระดับที่พบได้ทั่วไปคือการพัฒนา การทดสอบ การสร้างแบบจำลอง และการใช้งานจริง (DEV, TEST, MODL, PROD) โดยซอฟต์แวร์จะถูกปรับใช้ไปยังแต่ละระดับตามลำดับ สภาพแวดล้อมอื่นๆ ที่พบได้ทั่วไป ได้แก่ การควบคุมคุณภาพ (QC) สำหรับการทดสอบการยอมรับแซนด์บ็อกซ์หรือสภาพแวดล้อมทดลอง (EXP) สำหรับการทดลองที่ไม่ได้ตั้งใจจะนำไปใช้ในสภาพแวดล้อมการใช้งานจริง และการกู้คืนระบบในกรณีเกิดภัยพิบัติ เพื่อให้สามารถสำรองข้อมูลได้ทันทีในกรณีที่เกิดปัญหาในสภาพแวดล้อมการใช้งานจริง สถาปัตยกรรมอีกแบบที่พบได้ทั่วไปคือการพัฒนา การทดสอบ การยอมรับ และการใช้งานจริง (DTAP)

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

คำจำกัดความและขอบเขตที่แน่นอนระหว่างสภาพแวดล้อมนั้นแตกต่างกันไป – การทดสอบอาจถือเป็นส่วนหนึ่งของการพัฒนา การยอมรับอาจถือเป็นส่วนหนึ่งของการทดสอบ ส่วนหนึ่งของขั้นตอน หรืออาจแยกต่างหาก เป็นต้น ระดับหลักจะดำเนินการตามลำดับ โดยมีการปรับใช้ ( rolled outหรือpushed ) เวอร์ชันใหม่ไปยังแต่ละระดับตามลำดับ^{[ 1 ] [ 2 ]}ระดับการทดลองและการกู้คืน หากมี จะอยู่นอกเหนือกระบวนการนี้ – เวอร์ชันทดลองถือเป็นเวอร์ชันสุดท้าย ในขณะที่การกู้คืนมักจะเป็นเวอร์ชันเก่าหรือเวอร์ชันซ้ำของเวอร์ชันใช้งานจริง ซึ่งจะถูกปรับใช้หลังจากเวอร์ชันใช้งานจริง ในกรณีที่เกิดปัญหา สามารถย้อนกลับไปยังเวอร์ชันเก่าได้ โดยง่ายที่สุดคือการ push เวอร์ชันเก่าราวกับว่าเป็นเวอร์ชันใหม่ ขั้นตอนสุดท้าย การปรับใช้ไปยังเวอร์ชันใช้งานจริง ("pushing to prod") เป็นขั้นตอนที่ละเอียดอ่อนที่สุด เนื่องจากปัญหาใด ๆ จะส่งผลกระทบต่อผู้ใช้ทันที สำหรับขั้นตอนนี้ มักจะมีการจัดการที่แตกต่างออกไป อย่างน้อยก็มีการตรวจสอบอย่างระมัดระวังมากขึ้น และในบางกรณีมีการปรับใช้เป็นระยะ หรือเพียงแค่ต้องสลับสวิตช์ ทำให้สามารถย้อนกลับได้อย่างรวดเร็ว ควรหลีกเลี่ยงชื่อเช่น การประกันคุณภาพ (QA) QA ไม่ได้หมายถึงการทดสอบซอฟต์แวร์การทดสอบมีความสำคัญ แต่แตกต่างจาก QA

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

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

ตารางด้านล่างนี้แสดงรายการระดับชั้นที่แบ่งย่อยอย่างละเอียด

สภาพแวดล้อมการพัฒนา (dev) คือสภาพแวดล้อมที่ใช้ในการพัฒนาซอฟต์แวร์ โดยพื้นฐานแล้วคือเวิร์กสเตชันของนักพัฒนาแต่ละคน ซึ่งแตกต่างจากสภาพแวดล้อมเป้าหมายในหลายๆ ด้าน – เป้าหมายอาจไม่ใช่คอมพิวเตอร์ตั้งโต๊ะ (อาจเป็นสมาร์ทโฟนระบบฝังตัว เครื่องคอมพิวเตอร์ แบบไม่มีหน้าจอในศูนย์ข้อมูล ฯลฯ) และถึงแม้จะคล้ายคลึงกัน สภาพแวดล้อมของนักพัฒนาจะรวมถึงเครื่องมือพัฒนา เช่นคอมไพเลอร์สภาพแวดล้อมการพัฒนาแบบบูรณาการ ไลบรารีเวอร์ชันต่างๆ หรือเพิ่มเติม และซอฟต์แวร์สนับสนุน ฯลฯ ซึ่งไม่มีอยู่ในสภาพแวดล้อมของผู้ใช้

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

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

การทดสอบประเภทต่างๆ แนะนำสภาพแวดล้อมการทดสอบประเภทต่างๆ ซึ่งบางส่วนหรือทั้งหมดอาจเป็นแบบเสมือนจริง^{[ 4 ]}เพื่อให้สามารถดำเนินการทดสอบแบบขนานได้อย่างรวดเร็ว ตัวอย่างเช่น การทดสอบอินเทอร์เฟซผู้ใช้อัตโนมัติ^{[ 5 ]}อาจเกิดขึ้นกับระบบปฏิบัติการและจอแสดงผลเสมือนหลายระบบ (จริงหรือเสมือน) การทดสอบประสิทธิภาพอาจต้องใช้การกำหนดค่าฮาร์ดแวร์พื้นฐานทางกายภาพที่เป็นมาตรฐาน เพื่อให้สามารถเปรียบเทียบผลการทดสอบประสิทธิภาพได้เมื่อเวลาผ่านไป การทดสอบความพร้อมใช้งานหรือความทนทานอาจขึ้นอยู่กับโปรแกรมจำลองความล้มเหลวในฮาร์ดแวร์เสมือนและเครือข่ายเสมือน

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

สภาพแวดล้อมการทดสอบ การเตรียมการ หรือการผลิตล่วงหน้า คือสภาพแวดล้อมสำหรับการทดสอบที่มีลักษณะเหมือนกับสภาพแวดล้อมการผลิตทุกประการ^{[ 7 ]}โดยมีเป้าหมายเพื่อจำลองสภาพแวดล้อมการผลิตจริงให้ใกล้เคียงที่สุดเท่าที่จะเป็นไปได้ และอาจเชื่อมต่อกับบริการและข้อมูลการผลิตอื่นๆ เช่น ฐานข้อมูล ตัวอย่างเช่น เซิร์ฟเวอร์จะทำงานบนเครื่องระยะไกล แทนที่จะทำงานในพื้นที่ (เช่น บนเวิร์กสเตชันของนักพัฒนาในระหว่างการพัฒนา หรือบนเครื่องทดสอบเครื่องเดียวในระหว่างการทดสอบ) ซึ่งเป็นการทดสอบผลกระทบของเครือข่ายต่อระบบ

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

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

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

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

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

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

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

การพัฒนา การทดสอบ และการผลิต เป็นตัวแปรสภาพแวดล้อมที่เป็นที่รู้จักและมีการบันทึกไว้ในASP.NET Coreขึ้นอยู่กับตัวแปรที่กำหนดไว้ โค้ดจะถูกเรียกใช้และเนื้อหาจะถูกแสดงผลแตกต่างกัน และการตั้งค่าความปลอดภัยและการดีบักจะถูกนำมาใช้แตกต่างกัน^{[ 8 ]}

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