DevOps 파이프라인

1. 지속적 통합/지속적 제공/배포(CI/CD)

지속적 통합은 공동의 소스 코드 리포지토리에 자주 커밋하는 방식입니다. 코드 변경을 기존 코드베이스에 지속적으로 통합하여 서로 다른 개발자의 코드 변경 사항 간의 충돌을 신속하게 식별하고 비교적 쉽게 해결할 수 있습니다. 이 방식은 배포 효율성을 높이는 데 매우 중요합니다.

Atlassian은 트렁크 기반 개발이 지속적 통합에 필요한 사항이라고 생각합니다. 공유 소스 코드 리포지토리의 공동 브랜치에 자주 커밋하지 않으면 지속적 통합을 하는 것이 아닙니다. 빌드 및 테스트 프로세스가 자동화되어 있지만 개발자가 공유 브랜치에 자주 통합되지 않는 격리되고 오래된 기능 브랜치에서 작업하는 경우 지속적 통합을 하는 것이 아닙니다.

지속적 제공은 애플리케이션의 소스 코드의 “메인” 또는 “트렁크” 브랜치가 항상 릴리스 가능한 상태가 되도록 합니다. 즉, 금요일 오후 4시 30분에 경영진이 사무실로 와서 “지금 최신 버전을 출시해야 한다”고 말하면 장애를 두려워하지 않고 버튼 한 번으로 해당 버전을 배포할 수 있습니다.

즉, 프로덕션 환경과 최대한 동일한 사전 프로덕션 환경을 만들고 자동화된 테스트가 실행되도록 보장하여 코드를 주 브랜치 또는 트렁크 브랜치에 병합하기 전에 오류를 유발할 수 있는 모든 변수를 식별합니다.

지속적 배포에는 새로운 버전의 소프트웨어가 인력의 개입 없이 검증되고 프로덕션 환경에 배포되는 매우 강력한 수준의 지속적인 테스트와 운영이 수반됩니다.

이것은 드물고 대부분의 경우 불필요합니다. 일반적으로 이러한 수준의 자동화를 필요로 하거나 원하는 곳은 수백 또는 수천 명의 개발자가 있고 매일 릴리스를 여러 차례 하는 유니콘 비즈니스뿐입니다.

지속적 제공과 지속적 배포의 차이를 단순하게 설명하자면 제공은 FedEx 배달원이 택배 상자를 전달하는 것이고, 배포는 상자를 열고 내용물을 사용하는 것이라고 말할 수 있습니다. 상자를 수령한 시점부터 개봉 시점 사이에 상품을 변경해야 하는 경우 제조업체는 곤란한 상황에 놓일 것입니다.

2. 지속적인 피드백

소프트웨어 개발에서 오래된 워터폴 방식의 가장 큰 문제점 중 하나이며, 결과적으로 애자일 방법론을 설계한 이유는 시기적절한 피드백의 부족했기 때문이었습니다. 아이디어에서 구현에 이르기까지 새 기능을 출시하는 데 몇 개월 또는 몇 년이 소요된 경우, 최종 결과는 고객이 예상했거나 기대했던 것과 다를 수밖에 없었습니다. 애자일 관행은 개발자가 이해 관계자로부터 더 빠르게 피드백을 수신할 수 있도록 보장합니다. 이제 개발자는 DevOps를 통해 이해 관계자뿐만 아니라 파이프라인에서 코드에 대한 체계적인 테스트 및 모니터링을 진행하여 지속적인 피드백을 받을 수 있습니다.

지속적 테스트는 모든 DevOps 파이프라인의 중요한 구성 요소이며 지속적인 피드백을 가능하게 만드는 주요 구성 요소입니다. DevOps 프로세스에서 변경은 개발에서 테스트, 배포에 이르기까지 지속적으로 이동하므로 릴리스 속도가 빨라질 뿐만 아니라 더 높은 품질의 제품으로 이어집니다. 즉, 모든 빌드 변경에서 실행되는 단위 테스트, 스모크 테스트, 기능 테스트 및 엔드투엔드 테스트를 포함하여 파이프라인 전체에서 자동화된 테스트를 수행하게 됩니다.

지속적 모니터링은 지속적인 피드백의 또 다른 중요한 구성 요소입니다. DevOps 접근 방식에는 스테이징, 테스트 및 개발 환경에서도 지속적인 모니터링을 사용하는 것이 수반됩니다. 사전 프로덕션 환경에서 비정상적인 동작을 모니터링하는 것이 유용할 때도 있지만, 일반적으로 프로덕션 환경에서 애플리케이션의 상태와 성능을 지속적으로 평가하는 데 사용하는 접근 방식입니다.

이 기능을 제공하는 도구와 서비스는 아주 많으며, 여기에는 서버 리소스, 네트워킹 등의 온프레미스 또는 클라우드 인프라 모니터링이나 애플리케이션 또는 API 인터페이스의 성능 모니터링이 포함될 수 있습니다.

3. 지속적 운영

지속적 운영은 비교적 새롭고 덜 일반적인 용어이며 정의가 다양합니다. 한 가지 방법은 “지속적인 가동 시간”으로 해석하는 것입니다. 파란색/녹색 배포 전략에서 하나는 “파란색"(공개적으로 액세스)이고 다른 하나는 “녹색"(공개적으로 액세스할 수 없음)인 두 개의 개별 프로덕션 환경을 예로 들어 보겠습니다. 이 경우 새 코드가 녹색 환경에 배포되고, 기능이 확인되면 스위치가 전환되고(일반적으로 부하 분산 장치에서) 트래픽이 “파란색” 시스템에서 “녹색” 시스템으로 전환됩니다. 그 결과 최종 사용자의 가동 중지 시간이 발생하지 않습니다.

지속적 운영은 지속적 알림이라고도 생각할 수 있습니다. 이것은 엔지니어링 직원이 대기 중이며 애플리케이션이나 인프라에 성능 이상이 발생할 경우 알림을 받는다는 개념입니다. 대부분의 경우 지속적 알림은 지속적 모니터링과 함께 진행됩니다.