아티클
튜토리얼
대화형 가이드
DevOps 파이프라인
DevOps 파이프라인은 개발자와 운영 전문가가 협업하여 코드를 빌드하고 프로덕션 환경에 배포할 수 있도록 하는 일련의 자동화된 프로세스 및 도구입니다.
Tom Hall
DevOps 애드보케이트 및 전문가
DevOps는 개발과 운영을 분리하는 사일로화된 조직 구조를 혁신한다는 점에서 대변혁입니다. 그 결과로, 개발자와 운영 전문가들이 협업하고 자동화를 수용하며 배포 속도를 높이고 유연성을 높일 수 있는 문화적 변화로 이어집니다.
그 결과로 만들어지는 DevOps 구조에는 분명한 이점이 있습니다. DevOps 방식을 채택한 팀은 배포 파이프라인을 개선 및 간소화하여 인시던트의 빈도와 영향을 줄일 수 있습니다. "직접 구축하고 직접 운영"하는 DevOps 관행은 빠르게 일반화되고 있으며 그만한 이유가 있습니다. 2020 DevOps 트렌드 설문조사의 거의 모든 응답자(99%)는 DevOps가 조직에 긍정적인 영향을 미쳤다고 밝혔고, 거의 절반은 출시 시간을 단축하고 배포 빈도를 개선했다고 답했습니다.
그러나 DevOps를 구현하기란 말처럼 쉽지 않습니다. DevOps를 성공적으로 구현하려면 적절한 인력, 프로세스 및 도구가 필요합니다.
DevOps 파이프라인이란 무엇입니까?
DevOps 파이프라인은 개발자와 운영 전문가가 유기적으로 일하여 코드를 빌드하고 프로덕션 환경에 배포할 수 있도록 하는 일련의 자동화된 프로세스 및 도구입니다. DevOps 파이프라인은 조직마다 다를 수 있지만 일반적으로 빌드 자동화/지속적 통합, 자동화 테스트, 검증 및 보고가 포함됩니다. 또한 코드를 다음 단계로 진행하기 전에 인력의 개입이 필요한 하나 이상의 수동 게이트가 포함될 수 있습니다.
연속성은 DevOps 파이프라인의 차별화된 특징입니다. 여기에는 지속적 통합, CI/CD(지속적 제공/배포), 지속적 피드백 및 지속적 운영이 포함됩니다. 일회성 테스트 또는 예약된 배포 대신 각 기능이 지속적으로 수행됩니다.
관련 자료
무료로 사용해보기
관련 자료
DevOps 도구에 대해 자세히 알아보기
DevOps 파이프라인 구축 시 고려 사항
하나의 표준 DevOps 파이프라인이란 없으므로, 조직의 DevOps 파이프라인 설계 및 구현은 기술 스택, DevOps 엔지니어의 경험 수준, 예산 등에 따라 달라집니다. DevOps 엔지니어는 코딩, 인프라 관리, 시스템 관리 및 DevOps 도구 체인을 포함하여 개발 및 운영에 대한 광범위한 지식을 갖춰야 합니다.
또한 각 조직에는 프로세스에 영향을 줄 수 있는 서로 다른 기술 스택이 있습니다. 예를 들어, 코드베이스가 node.js인 경우 고려할 요소에는 로컬 프록시 npm 레지스트리를 사용하는지 여부, 파이프라인의 모든 단계에서 소스 코드를 다운로드하고 'npm install'을 실행하는지 또는 한 번 수행하고 파이프라인에서 이동하는 아티팩트를 만드는지 여부가 포함됩니다. 또는 애플리케이션이 컨테이너 기반인 경우, 로컬 또는 원격 컨테이너 레지스트리를 사용하고 컨테이너를 한 번 빌드한 후 파이프라인에서 이동할지, 아니면 모든 단계에서 다시 빌드할지 결정해야 합니다.
모든 파이프라인은 고유하지만, 대부분의 조직에서는 비슷한 기본 구성 요소를 사용합니다. 각 단계는 파이프라인의 다음 단계로 이동하기 전에 성공 여부를 평가합니다. 오류가 발생하면 파이프라인을 중지하고 개발자에게 피드백을 제공합니다.
DevOps 파이프라인의 구성 요소
1. 지속적 통합/지속적 제공/배포(CI/CD)
지속적 통합은 공동의 소스 코드 리포지토리에 자주 커밋하는 방식입니다. 코드 변경을 기존 코드베이스에 지속적으로 통합하여 서로 다른 개발자의 코드 변경 사항 간의 충돌을 신속하게 식별하고 비교적 쉽게 해결할 수 있습니다. 이 방식은 배포 효율성을 높이는 데 매우 중요합니다.
Atlassian은 트렁크 기반 개발이 지속적 통합에 필요한 사항이라고 생각합니다. 공유 소스 코드 리포지토리의 공동 브랜치에 자주 커밋하지 않으면 지속적 통합을 하는 것이 아닙니다. 빌드 및 테스트 프로세스가 자동화되어 있지만 개발자가 공유 브랜치에 자주 통합되지 않는 격리되고 오래된 기능 브랜치에서 작업하는 경우 지속적 통합을 하는 것이 아닙니다.
지속적 제공은 애플리케이션의 소스 코드의 “메인” 또는 “트렁크” 브랜치가 항상 릴리스 가능한 상태가 되도록 합니다. 즉, 금요일 오후 4시 30분에 경영진이 사무실로 와서 “지금 최신 버전을 출시해야 한다”고 말하면 장애를 두려워하지 않고 버튼 한 번으로 해당 버전을 배포할 수 있습니다.
즉, 프로덕션 환경과 최대한 동일한 사전 프로덕션 환경을 만들고 자동화된 테스트가 실행되도록 보장하여 코드를 주 브랜치 또는 트렁크 브랜치에 병합하기 전에 오류를 유발할 수 있는 모든 변수를 식별합니다.
지속적 배포에는 새로운 버전의 소프트웨어가 인력의 개입 없이 검증되고 프로덕션 환경에 배포되는 매우 강력한 수준의 지속적인 테스트와 운영이 수반됩니다.
이것은 드물고 대부분의 경우 불필요합니다. 일반적으로 이러한 수준의 자동화를 필요로 하거나 원하는 곳은 수백 또는 수천 명의 개발자가 있고 매일 릴리스를 여러 차례 하는 유니콘 비즈니스뿐입니다.
지속적 제공과 지속적 배포의 차이를 단순하게 설명하자면 제공은 FedEx 배달원이 택배 상자를 전달하는 것이고, 배포는 상자를 열고 내용물을 사용하는 것이라고 말할 수 있습니다. 상자를 수령한 시점부터 개봉 시점 사이에 상품을 변경해야 하는 경우 제조업체는 곤란한 상황에 놓일 것입니다.
2. 지속적인 피드백
소프트웨어 개발에서 오래된 워터폴 방식의 가장 큰 문제점 중 하나이며, 결과적으로 애자일 방법론을 설계한 이유는 시기적절한 피드백의 부족했기 때문이었습니다. 아이디어에서 구현에 이르기까지 새 기능을 출시하는 데 몇 개월 또는 몇 년이 소요된 경우, 최종 결과는 고객이 예상했거나 기대했던 것과 다를 수밖에 없었습니다. 애자일 관행은 개발자가 이해 관계자로부터 더 빠르게 피드백을 수신할 수 있도록 보장합니다. 이제 개발자는 DevOps를 통해 이해 관계자뿐만 아니라 파이프라인에서 코드에 대한 체계적인 테스트 및 모니터링을 진행하여 지속적인 피드백을 받을 수 있습니다.
지속적 테스트는 모든 DevOps 파이프라인의 중요한 구성 요소이며 지속적인 피드백을 가능하게 만드는 주요 구성 요소입니다. DevOps 프로세스에서 변경은 개발에서 테스트, 배포에 이르기까지 지속적으로 이동하므로 릴리스 속도가 빨라질 뿐만 아니라 더 높은 품질의 제품으로 이어집니다. 즉, 모든 빌드 변경에서 실행되는 단위 테스트, 스모크 테스트, 기능 테스트 및 엔드투엔드 테스트를 포함하여 파이프라인 전체에서 자동화된 테스트를 수행하게 됩니다.
지속적 모니터링은 지속적인 피드백의 또 다른 중요한 구성 요소입니다. DevOps 접근 방식에는 스테이징, 테스트 및 개발 환경에서도 지속적인 모니터링을 사용하는 것이 수반됩니다. 사전 프로덕션 환경에서 비정상적인 동작을 모니터링하는 것이 유용할 때도 있지만, 일반적으로 프로덕션 환경에서 애플리케이션의 상태와 성능을 지속적으로 평가하는 데 사용하는 접근 방식입니다.
이 기능을 제공하는 도구와 서비스는 아주 많으며, 여기에는 서버 리소스, 네트워킹 등의 온프레미스 또는 클라우드 인프라 모니터링이나 애플리케이션 또는 API 인터페이스의 성능 모니터링이 포함될 수 있습니다.
3. 지속적 운영
지속적 운영은 비교적 새롭고 덜 일반적인 용어이며 정의가 다양합니다. 한 가지 방법은 “지속적인 가동 시간”으로 해석하는 것입니다. 파란색/녹색 배포 전략에서 하나는 “파란색"(공개적으로 액세스)이고 다른 하나는 “녹색"(공개적으로 액세스할 수 없음)인 두 개의 개별 프로덕션 환경을 예로 들어 보겠습니다. 이 경우 새 코드가 녹색 환경에 배포되고, 기능이 확인되면 스위치가 전환되고(일반적으로 부하 분산 장치에서) 트래픽이 “파란색” 시스템에서 “녹색” 시스템으로 전환됩니다. 그 결과 최종 사용자의 가동 중지 시간이 발생하지 않습니다.
지속적 운영은 지속적 알림이라고도 생각할 수 있습니다. 이것은 엔지니어링 직원이 대기 중이며 애플리케이션이나 인프라에 성능 이상이 발생할 경우 알림을 받는다는 개념입니다. 대부분의 경우 지속적 알림은 지속적 모니터링과 함께 진행됩니다.
결론...
DevOps의 핵심은 소프트웨어 개발, 배포 및 운영을 간소화하는 것입니다. DevOps 파이프라인은 이러한 아이디어가 실제로 구현되는 방식이며, 코드 통합에서 애플리케이션 운영에 이르기까지 모든 것이 지속적이어야 합니다.
지속적 제공에 대해 자세히 알아보려면 통합 CI/CD로 빌드, 테스트 및 배포할 수 있는 Bitbucket을 통한 지속적 제공 자습서를 확인하세요. 이 자습서는 초보자와 전문가가 Bitbucket을 통해 지속적 제공을 달성하는 데 도움이 됩니다. 바로 시작할 준비가 되셨습니까? 무료로 Bitbucket Pipelines를 시작하세요.
이 기사 공유
다음 주제
여러분께 도움을 드릴 자료를 추천합니다.
이러한 리소스에 책갈피를 지정하여 DevOps 팀의 유형에 대해 알아보거나 Atlassian에서 DevOps에 대한 지속적인 업데이트를 확인하세요.
DevOps 커뮤니티
DevOps 학습 경로
