[DevOps] SW 개발 환경(local, dev, staging, QA, production)

현업에서 서비스 개발을 하다보면 개발 환경에 대한 이해가 필요합니다.

 

대기업이나 안정성이 매우 중요한 프로젝트에서는 보통 6가지 개발 환경으로 구성합니다. (local- > dev -> integration -> staging -> QA -> production)

 

모든 환경을 모두 구성할 필요는 없지만 최소한 3가지 개발환경 (dev -> staging -> production)은 구성합니다.

 

논리적으로 보는 개발 환경

 

서버의 물리적 구조로 보는 개발 환경

Local

개발자가 본인의 PC에서 개발하는 환경을 말합니다.

요즘은 보통 각각의 개발자가 git에서 master/dev 브랜치를 local machine으로 clone하여 개발하게 됩니다.

local 환경에서 가장 중요한 부분은 개발도구나 라이브러리에 대한 통합이 필요하다는 점입니다.

그렇지 않으면 local에서 잘 수행되던 코드가 dev 동작하지 않을 수 있습니다.

최근에는 프로젝트내에 사용되는 라이브러리의 dependency를 관리해주는 도구들이 많이 나와있어 가능하면 그런 도구를 활용하는 것을 추천합니다.

 

dev

개발자들이 각자 개발한 내용들을 합친 뒤 테스트 하는 환경입니다.

local에서 개발자들이 각자 개발한 코드에 대해 간단한 unit test를 수행한 뒤 pull request를 통해 dev 브랜치로 merge 합니다.

CI/CD가 잘 구성되어 있는 프로젝트라면 dev 브랜치로 merge되면 자동적으로 dev 환경에 배포됩니다.

주로 기능에 대한 테스트를 많이 이루어집니다. 그렇기 때문에 리소스는 구동이 가능한 최소한으로 잡고 구성합니다.

리소스가 작기 때문에 트래픽이나 그 외 성능과 관련된 부분은 보통 이후 QA/staging 환경에서 테스트 합니다.

 

Integration

통합 개발 환경은 여러개의 컴포넌트를 동시 개발하고 각 컴포넌트가 다른컴포넌트에 대해서 dependecy를 가지고 있을 때 컴포넌트를 통합 및 테스트 하는 환경으로 사용합니다.

dev 환경에서 코드가 정상적으로 동작한다면 그 때 통합 개발 환경에서 테스트를 진행합니다.

dev 환경과 마찬가지로 기능 테스트를 위한 최소한의 리소스로 구성합니다.

 

QA

말 그대로 QA를 위한 환경입니다.

테스터가 기능/비 기능에 대한 테스트 합니다.

만약 여기에서 테스터에 의해 이슈가 발견된다면 개발자에게 전달되고, 개발자는 해당 이슈를 local 환경에서 다시 수정을 시작하게 됩니다.

 

staging

다음 버전의 코드로 운영 환경과 거의 동일한 환경을 만들어 릴리즈 전에 테스트하는 환경입니다.

일반적으로 release 브랜치가 테스트 된다고 볼 수 있습니다.

운영 환경으로 이전하기 전에, 여러 가지 비 기능적인 부분 (보안, 성능, 장애 등)을 검증하는 환경입니다.

실제 트래픽을 미러링하여 테스트 하기도 합니다.

 

production

실제 서비스를 위한 운영 환경

릴리즈 버전의 코드가 수행되는 client나 유저에 의해 사용되는 환경입니다.

릴리즈 계획이 없다면 수정이 없어야 합니다.

(협의되지 않은 hotfix나 잠수함패치는 서비스에 큰 악영향을 줄 수 있으니 개발자가 임의로 배포하면 안됩니다!!!)

릴리즈 브랜치를 가지고 배포하고 배포가 정상적으로 이루어졌다면 마스터(메인) 브랜치로 merge합니다.