도입 환경

Deployment environment

소프트웨어 배포에서 환경 또는 계층은 컴퓨터 프로그램 또는 소프트웨어 구성 요소가 배포되고 실행되는 컴퓨터 시스템 또는 시스템 세트입니다.같은 머신에서 프로그램을 개발하여 즉시 실행하는 등 간단한 경우에는 단일 환경이 존재할 수 있지만 산업용 사용에서는 개발 환경(원래 변경이 이루어지는 곳)과 운영 환경(최종 사용자가 사용하는 곳)이 분리되어 있는 경우가 많습니다.이 구조화된 릴리스 관리 프로세스를 통해 문제 발생 시 단계적 도입(롤아웃), 테스트 및 롤백을 수행할 수 있습니다.

환경에 따라 크기가 크게 다를 수 있습니다.개발 환경은 일반적으로 개별 개발자의 워크스테이션이지만 실제 가동 환경은 데이터 센터에 지리적으로 분산된 다수의 머신 또는 클라우드 컴퓨팅에 포함된 가상 머신의 네트워크일 수 있습니다.코드, 데이터 및 구성을 병렬로 도입할 수 있으며, 대응하는 계층에 접속할 필요가 없습니다.예를 들어, 사전 실가동 코드가 실가동 데이터베이스에 접속되는 경우가 있습니다.

아키텍처

도입 아키텍처는 크게 다르지만, 일반적으로 계층은 개발(DEV)에서 시작하여 운영(PROD)에서 종료하는 것으로 예약됩니다.일반적인 4계층 아키텍처는 개발, 테스트, 모델, 실가동(DEV, TEST, MODL, PROD)이며, 각 아키텍처에 소프트웨어가 순서대로 도입됩니다.기타 일반적인 환경에는 수용 테스트의 QC(Quality Control), 실가동용으로 진행되지 않는 실험의 경우 샌드박스 또는 EXP(Experimental) 및 실가동 시 즉시 폴백을 제공하는 Disaster Recovery가 있습니다.또 다른 일반적인 아키텍처는 개발, 테스트, 수용 및 운영(DTAP)입니다.

이 언어는 리모트 데이터 센터에서 서버를 실행하는 서버 프로그램에 특히 적합합니다.어플리케이션이나 클라이언트 등 최종 사용자의 디바이스에서 실행되는 코드에 대해서는 사용자 환경(USER) 또는 로컬 환경(LOCAL)을 대신 참조할 수 있습니다.

환경마다 정확한 정의와 경계가 다릅니다.테스트는 개발의 일부로 간주되거나, 수용은 테스트의 일부로 간주되거나, 스테이지의 일부로 간주되거나, 별개의 것으로 간주될 수 있습니다.메인 계층은 순서대로 진행되며 새로운 릴리스가 각 [1][2]계층에 차례로 배치(롤아웃 또는 푸시)됩니다.시험판 및 리커버리 계층이 존재하는 경우 이 흐름에서 제외됩니다.실험판 릴리스는 터미널이지만 리커버리 버전은 일반적으로 운용 후 도입되는 오래된 버전 또는 중복 버전입니다.문제가 있는 경우 이전 릴리스로 롤백할 수 있습니다.대부분의 경우 이전 릴리스를 새 릴리스처럼 푸시하기만 하면 됩니다.마지막 단계('push to prod')는 사용자에게 즉각적인 영향을 미치기 때문에 가장 중요한 절차입니다.이 때문에, 적어도 주의 깊게 감시되고 있는 경우나, 단계적인 롤아웃을 실시하거나 스위치 플립만을 필요로 하는 경우에 따라서는, 신속한 롤백이 가능하게 됩니다.QA(Quality Assurance)라는 이름은 피하는 것이 좋습니다.QA는 소프트웨어 테스트를 의미하는 것이 아닙니다.테스트는 중요하지만 QA와는 다릅니다.

전개는 이 통상적인 프로세스 이외에서 이루어지는 경우가 있습니다.주로 긴급한 변경이나 비교적 사소한 변경을 제공하기 위해 완전한 릴리스가 필요 없습니다.이는 단일 패치, 대규모 서비스 팩 또는 소규모 핫픽스로 구성됩니다.

환경에는 매우 다양한 크기가 있습니다.일반적으로 개발은 개별 개발자의 워크스테이션(수천명의 개발자가 있을 수 있지만)이지만, 실제 가동은 지리적으로 분산되어 있을 수 있습니다.테스트 및 QC는 이들 자원에 따라 소규모 또는 대규모일 수 있습니다.또한 스테이징은 1대의 머신(simi)에서 가능합니다.라르에서 카나리아로)를 복제한 것입니다.

환경

다음 표는 세분화된 계층[citation needed] 목록을 설명합니다.

환경/계층명 묘사
현지의 개발자의 데스크톱/워크스테이션
개발/트렁크 개발자가 유닛 테스트를 수행할 수 있는 샌드박스 역할을 하는 개발 서버
통합 CI 구축 목표 또는 개발자의 부작용 테스트용
테스트/테스트/QC/내부 승인 인터페이스 테스트가 실행되는 환경.품질관리팀은 새로운 코드가 기존 기능에 영향을 미치지 않도록 하고 새로운 코드를 테스트 환경에 도입한 후 시스템의 주요 기능을 테스트합니다.
스테이징/스테이지/모델/프로덕션 전/외부 클라이언트 수용/데모 실가동 환경의 거울
실가동/라이브 최종 사용자/클라이언트 서비스

발전

「개발 환경」은, 여기서 리다이렉트 됩니다.기타 용도는 통합 개발 환경을 참조하십시오.
참고 항목: 샌드박스(소프트웨어 개발)

개발환경(dev)은 소프트웨어 변경사항이 개발되는 환경이며, 가장 단순한 것은 개별 개발자의 워크스테이션입니다.이는 다양한 면에서 궁극적인 타깃 환경과는 다릅니다.대상은 데스크톱 컴퓨터(스마트폰, 임베디드 시스템, 데이터센터 헤드리스 머신 등)가 아닐 수 있습니다.또한 이와 유사한 경우에도 개발자의 환경에는 컴파일러, 통합 개발 환경 등의 개발 도구가 포함됩니다.사용자 환경에 존재하지 않는 라이브러리 및 지원 소프트웨어 등의 추가 버전

리비전 제어의 맥락에서, 특히 복수의 개발자에 대해서는, 보다 세밀한 구별이 있습니다.개발자는 머신에 소스 코드의 작업 카피를 가지고 있으며, 변경은 개발 방법론에 따라 트렁크 또는 브랜치에 커밋되어 저장소에 제출됩니다.변경이 이루어지고 시행되는 개별 워크스테이션의 환경은 로컬 환경 또는 샌드박스라고 할 수 있습니다.깨끗한 환경에서 저장소의 소스 코드 복사본을 구축하는 것은 별개의 단계이며, 통합(이질적인 변경 통합)의 일부입니다.이 환경을 통합 환경 또는 개발 환경이라고 부릅니다.지속적인 통합에서는 이 작업이 모든 리비전에 대해 빈번히 수행됩니다.「저장소의 변경을 커밋한다」라고 하는 소스코드 레벨의 개념은, 트렁크 또는 브랜치를 구축한 후에, 로컬(개별 개발자의 환경)에서 통합(클린 빌드)으로 릴리스 하는 것에 대응합니다.이 단계에서 릴리스가 잘못되었을 경우는 빌드가 파손된 것을 의미하며, 릴리스의 롤백은 롤백에 대응합니다.k 그 시점 이후의 모든 변경 또는 가능하면 브레이크 변경만 취소한다.

테스트

다음 항목도 참조하십시오.테스트 환경 관리

시험 환경의 목적은 인간 시험자가 자동화된 검사 또는 비자동화 기법을 통해 새롭고 변경된 코드를 행사할 수 있도록 하는 것이다.개발자가 개발 환경에서 유닛 테스트를 통해 새로운 코드와 구성을 수락하면 아이템은 하나 이상의 테스트 [3]환경으로 이동합니다.테스트 실패 시 테스트 환경에서 테스트 플랫폼에서 장애가 발생한 코드를 삭제하고 담당 개발자에게 연락하여 자세한 테스트 및 결과 로그를 제공할 수 있습니다.모든 테스트에 합격하면 테스트 환경 또는 테스트를 제어하는 연속적인 통합 프레임워크에 의해 코드가 다음 전개 환경으로 자동 승격됩니다.

다양한 유형의 테스트를 통해 다양한 유형의 테스트 환경을 제안할 수 있으며, 이들 환경의 일부 또는 전부를 가상화하여[4] 신속하고 병렬적인 테스트를 수행할 수 있습니다.예를 들어 자동 사용자 인터페이스[5] 테스트는 여러 가상 운영 체제 및 디스플레이(실제 또는 가상)에서 수행될 수 있습니다.퍼포먼스 테스트에서는 퍼포먼스 테스트 결과를 시간에 따라 비교할 수 있도록 표준화된 물리 베이스라인 하드웨어 구성이 필요할 수 있습니다.가용성 또는 내구성 테스트는 가상 하드웨어 및 가상 네트워크의 장애 시뮬레이터에 따라 달라집니다.

테스트는 테스트 환경의 정교함에 따라 직렬(하나씩 차례로) 또는 병렬(일부 또는 모두 한 번에)로 이루어집니다.민첩한 기타 생산성 높은 소프트웨어 개발 관행의 중요한 목표는 소프트웨어 설계 또는 사양에서 [6]프로덕션 제공까지의 시간을 단축하는 것입니다.고도로 자동화된 병렬화된 테스트 환경은 신속한 소프트웨어 개발에 중요한 역할을 합니다.

스테이징

스테이지, 스테이징, 또는 프리 프로덕션 환경은 실제 가동 [7]환경과 완전히 유사한 테스트 환경입니다.실제 운영 환경을 최대한 가깝게 미러링하고 데이터베이스와 같은 다른 운영 서비스 및 데이터에 연결할 수 있습니다.예를 들어, 서버는 로컬이 아닌 리모트 머신(개발중의 개발자의 워크스테이션 또는 테스트중의 단일의 테스트 머신)에서 가동됩니다.이러한 머신에서는, 시스템에의 네트워킹의 영향을 테스트합니다.

스테이징 환경의 주된 용도는 모든 설치/구성/이행 스크립트 및 절차를 실제 가동 환경에 적용하기 전에 테스트하는 것입니다.이를 통해 운영 환경에 대한 모든 주요 및 소규모 업그레이드가 오류 없이 최소한의 시간 내에 안정적으로 완료됩니다.

스테이징의 또 다른 중요한 용도는 퍼포먼스 테스트, 특히 부하 테스트입니다.이는 환경에 영향을 받기 때문입니다.

또한 스테이징은 고객을 선정하기 위해 새로운 기능을 미리 보거나 외부 종속성의 라이브 버전과의 통합을 검증하기 위해 일부 조직에서 사용됩니다.

생산.

참고 항목: 운영 지원

실가동 환경은, 유저가 직접 대화하는 환경이기 때문에, 특히 서버의 경우는, 라이브라고도 불립니다.

실가동으로의 도입은 가장 중요한 순서입니다.새로운 코드를 직접 도입하거나(오래된 코드를 덮어쓰기하여 한 번에 1개의 복사본만 존재), 또는 설정 변경을 도입하여 실행할 수 있습니다.여기에는 다양한 형식이 있습니다.새로운 버전의 코드를 병렬로 설치하고 설정 변경을 사용하여 이들 사이에서 전환합니다.구 동작과 기능 플래그를 사용하여 새로운 버전의 코드를 전개합니다.플래그 플립을 실행하는 설정 변경을 사용하여 새로운 동작으로 전환합니다(1회 실행).오래된 코드(새로운 코드)를 ning하고 트래픽라우팅 레벨에서의 설정 변경으로 오래된 트래픽에서 새로운 트래픽으로 리다이렉트 합니다.이러한 작업은 한 번에 또는 단계적으로 수행될 수 있습니다.

새로운 릴리스를 도입하려면 일반적으로 핫스왑이 가능하지 않은 한 재부팅이 필요합니다.따라서 서비스 중단(통상 사용자 소프트웨어에서는 어플리케이션이 재부팅되는 경우) 또는 용장성이 필요합니다.로드 밸런서 뒤에서 인스턴스를 천천히 재시작하거나 새로운 서버를 사전에 기동한 후 트래픽을 리다이렉트하는 경우입니다.c를 새로운 서버에 접속합니다.

새로운 릴리스를 운용 환경에 도입할 때는 모든 인스턴스 또는 사용자에게 즉시 도입하지 않고 먼저 단일 인스턴스 또는 일부 사용자에게 전개한 후 모든 사용자에게 전개하거나 단계적으로 전개하여 최종적인 문제를 검출할 수 있습니다.이것은 실제 생산에서 이루어진 것을 제외하면 스테이징과 비슷하며, 석탄 채굴과 유사하게 카나리아 방출이라고 불립니다.이로 인해 여러 릴리스가 동시에 실행되기 때문에 복잡성이 증가하므로 호환성 문제를 피하기 위해 일반적으로 신속하게 종료됩니다.

프레임워크 통합

개발, 스테이징 및 실가동 환경변수는 ASP에 기재되어 있습니다.NET 코어정의된 변수에 따라 다른 코드가 실행되고 콘텐츠가 렌더링되며 다른 보안 및 디버깅 설정이 적용됩니다.[8]

「 」를 참조해 주세요.

레퍼런스

  1. ^ "Traditional Development/Integration/Staging/Production Practice for Software Development". Disruptive Library Technology Jester. December 4, 2006.
  2. ^ "Development Sandboxes: An Agile 'Best Practice'". www.agiledata.org.
  3. ^ Ellison, Richard (2016-06-20). "Software Testing Environments Best Practices". Software Testing Magazine. Martinig & Associates. Retrieved 2016-12-02. Once the developer performs the unit test cases, the code will be moved into QA to start testing. Often you will have a few environments for testing. For example you will have one set up for system testing and another that is used for performance testing and yet another that is used for user acceptance testing (UAT). This is caused by the unique needs for each type of testing.
  4. ^ Dubie, Denise (2008-01-17). "How to keep virtual test environments in check". Network World, Inc. IDG. Retrieved 2016-12-02. Virtual server technology makes it easy for enterprise companies to set up and tear down test environments in which they can ensure applications will run up to par on production servers and client machines.
  5. ^ "Use UI Automation To Test Your Code". Microsoft.com. Microsoft. Retrieved 2016-12-02. Automated tests that drive your application through its user interface (UI) are known as coded UI tests (CUITs). These tests include functional testing of the UI controls. They let you verify that the whole application, including its user interface, is functioning correctly. Coded UI Tests are particularly useful where there is validation or other logic in the user interface, for example in a web page.
  6. ^ Heusser, Matthew (2015-07-07). "Are you over-testing your software?". CIO.com. IDG. Retrieved 2016-12-03. Release candidate testing takes too long. For many agile teams, this is the single biggest challenge. Legacy applications start with a test window longer than the sprint.
  7. ^ Sharma, Anurag (2018). Test Environment Management. ITSM Press. p. 11. ISBN 9781912651269.
  8. ^ "Use multiple environments in ASP.NET Core". docs.microsoft.com. Retrieved 2019-04-05.