1. 소프트웨어 변경의 중요성
오늘날 기업은 급변하는 경쟁 환경, 진화하는 보안 요구 사항 및 성능 확장성의 과제에 직면 해 있습니다. 기업은 운영 안정성과 빠른 기능 개발 간의 격차를 해소해야합니다. CI / CD (Continuous Integration and Continuous Delivery)는 시스템 안정성과 보안을 유지하면서 소프트웨어를 빠르게 변경할 수있는 방법입니다.
2. 지속적 통합 / 지속적 전달 / 지속적 배포란
2.1. 지속적 통합(Continuous Integration)
개발자가 코드 변경 사항을 중앙 저장소에 정기적으로 병합 한 후 자동화 된 빌드 및 테스트가 실행되는 소프트웨어 개발 사례입니다.
CI의 주요 목표는 버그를 더 빨리 찾아서 해결하고 소프트웨어 품질을 개선하며 새로운 소프트웨어 업데이트의 유효성을 검사하고 릴리스하는 데 걸리는 시간을 줄이는 것입니다. 지속적인 통합은 작은 커밋과 작은 코드 변경에 집중하여 통합합니다. 개발자는 최소한 하루에 한 번 정기적으로 코드를 커밋합니다. 개발자는 빌드 서버로 푸시하기 전에 코드 저장소에서 코드를 가져와 로컬 호스트의 코드가 병합되도록합니다. 이 단계에서 빌드 서버는 다양한 테스트를 실행하고 코드 커밋을 수락하거나 거부합니다.
2.2. 지속적 전달(Continuous Delivery)
코드 변경이 자동으로 빌드, 테스트 및 프로덕션 릴리스 준비되는 소프트웨어 개발 사례입니다. 빌드 단계가 완료된 후 모든 코드 변경 사항을 테스트 환경, 프로덕션 환경 또는 둘 다에 배포하여 지속적인 통합을 확장합니다. 워크 플로 프로세스를 통해 지속적인 전달을 완전히 자동화하거나 중요한 단계에서 수동 단계를 통해 부분적으로 자동화 할 수 있습니다. 지속적인 전달이 제대로 구현되면 개발자는 항상 표준화 된 테스트 프로세스를 통과 한 배포 준비 빌드 아티팩트를 갖습니다.
2.3. 지속적 배포(Continuous Deployment)
지속적인 배포를 사용하면 개발자의 명시적인 승인없이 개정이 프로덕션 환경에 자동으로 배포되어 전체 소프트웨어 릴리스 프로세스가 자동화됩니다. 따라서 제품 수명주기 초기에 지속적인 고객 피드백 루프가 가능합니다.
※ 지속적 전달은 지속적 배포가 아닙니다
지속적인 전달에 대한 한 가지 오해는 자동화 된 테스트를 통과 한 직후 커밋 된 모든 변경 사항이 프로덕션에 적용된다고 생각하는 것입니다. 그러나 지속적인 전달의 요점은 생산에 모든 변경 사항을 즉시 적용하는 것이 아니라 모든 변경 사항이 생산에 적용되도록 준비하는 것입니다. 프로덕션 변경 사항을 배포하기 전에 프로덕션 배포가 승인되고 감사되도록 결정 프로세스를 구현할 수 있습니다. 이 결정은 사람이 만든 다음 툴링으로 실행할 수 있습니다. 지속적인 전달을 사용하면 실시간 결정이 기술적 결정이 아닌 비즈니스 결정이됩니다. 기술 검증은 모든 커밋마다 발생합니다.
3. 지속적 전달의 이점
3.1. 소프트웨어 릴리스 프로세스 자동화
코드의 빌드, 테스트, 릴리즈될 준비를 자동으로 실행하여 소프트웨어 전달이 효율적이고, 탄력적이며, 빠르고, 안전하게 만든다.
3.2. 개발자 생산성 향상
개발자들이 수동 작업에서 벗어나고, 복잡한 의존성에서 벗어나 새로운 기능을 제공하는데 집중할 수 있게하여 팀의 생산성을 높이는데 도움을 준다.
3.3. 코드 품질 향상
버그가 더 큰 문제로 커지기 전에 전달 과정에서 버그를 조기에 발견할 수 있게 한다. 전체 프로세스가 자동화되었기 때문에 추가 테스트 코드를 추가하기 쉽고, 빈번한 테스트 및 즉각적인 피드백을 빠르게 반복할 수 있다. 개발 과정에서 초기에 발견된 실수가 가장 쉽게 고쳐진다.
3.4. 더 빠른 업데이트 제공
고객에게 빠르고 자주 업데이트를 제공할 수 있게 도와준다. CI/CD가 구현되면 팀의 전체 속도가 증가하기 때문에 기업은 시장 변화, 보안 문제, 비용 문제에 대해 더 빠른 대응이 가능해진다.
4. 지속적 통합과 지속적 전달 구현하기
4.1. CI/CI 파이프라인 구성하기
CI/CD는 파이프라인으로 그려질 수 있다.
초기 단계에서 발견된 문제들은 코드가 파이프라인을 통해 진행되는 것을 막는다. 테스트 결과는 즉시 팀으로 보내지며 소프트웨어가 단계를 통과하지 못하면 추가 빌드 및 릴리스가 모두 중단됩니다. 이 단계들은 제안이다. 비즈니스 요구에 따라 단계를 조정할 수 있다. 조직은 시작 단계에서 모든 단계에서 다중 환경, 많은 테스트 단계 및 자동화를 통해 완전히 성숙한 파이프라인을 구축하려고 시도하지 말고 작은 단계부터 시작해야 한다. 성숙도가 높은 CI/CD 환경을 보유한 조직도 파이프라인을 지속적으로 개선해야 한다는 점을 명심하십시오.
1. 지속적 통합
CI/CD의 첫 번째 단계는 지속적 통합을 구축하는 것이다.
(1) Source 단계
개발자는 최대한 빨리 단위테스트를 만들고 중앙 리포지토리에 커밋하기 전에 테스트를 실행하도록 권장해야한다. 소프트웨어 개발 과정에서 일찍 잡힌 오류는 가장 저렴하고 쉽게 고칠 수 있다.
모든 개발자는 정기적으로 중앙 리포지토리에 코드를 커밋하고 모든 변경사항을 응용프로그램의 릴리즈 분기에 병합해야한다. 코드를 일찍, 그리고 자주 병합하는 개발자는 더 적은 오류를 발생시킨다.
(2) Build 단계
소스코드 저장소에 코드가 푸시되면 빌드 도구로 명령을 전달하여 코드를 빌드하고 유닛테스트를 실행해야한다. 빌드 프로세스는 빠른 피드백을 위해 모든 커밋에 대한 테스트가 이루어지도록 구성되어야 하며 단위 테스트, 스타일 체크, 정적분석과 같은 다른 품질 검사도 이 단계에서 이루어질 수 있다. 이 과정이 모두 끝나면 빌드 도구는 이미지, 스타일시트, 문서와 같은 아티팩트를 생성한다.
2. 지속적 전달
(3) Staging 단계
지속적 전달은 지속적 통합의 다음 단계로, 먼저 프로덕션 환경의 복제 환경인 스테이징 환경에서 애플리케이션 코드를 배포하고 더 많은 기능 테스트를 실행한다. 스테이징 환경은 미리 생성되어 있는 정적 환경이거나 코드로 구성된 인프라를 사용하여 동적 환경을 프로비저닝하거나 구성할 수 있다.
(3) Production 단계
코드로 스테이징 인프라 환경을 구성한 경우, 프로덕션 환경도 스테이징과 똑같은 방법으로 빠르게 구축이 가능하다.
3. 지속적 배포
CI/CD 파이프라인의 최종 단계는 지속적인 배포이다. 지속적 배포는 전체 소프트웨어 릴리즈 프로세스의 완전한 자동화 및 생산 환경에 배포하는 것을 포함한다. 완전히 성숙한 CI/CD 환경에서 프로덕션 환경으로까지의 경로가 모두 자동화된 상태에서 신뢰도 높은코드가 배포된다.
추가 가능한 개선 사항
- 특정 성능, 보안, UI 테스트를 위한 추가 스테이징 환경
- 인프라 및 구성 코드에 대한 유닛 테스트
- 코드 리뷰, 이슈트레킹, 이벤트 알림과 같은 다른 시스템 및 프로세스와의 통합
- 감사 및 비즈니스 승인을 위한 추가 단계
4.2. 팀
AWS는 CI/CD 환경을 구현하기 위해 애플리케이션 팀, 인프라 팀, 툴 팀 등 세 개의 개발자 팀을 구성할 것을 권장한다. 그 팀은 피자 두 판이 먹을 수 있는 그룹, 또는 10-12명 정도의 사람들보다 크지 않아야 한다. 이는 그룹 규모가 커지고 커뮤니케이션 회선이 늘어나면서 의미 있는 대화가 한계에 부딪힌다는 커뮤니케이션 규칙에 따른 것이다.
애플리케이션 팀(Application Team)
애플리케이션 팀이 애플리케이션을 만든다. 애플리케이션 개발자는 백로그, 스토리 및 단위 테스트를 가지고 기능을 개발한다. 이 팀의 조직 목표는 개발자가 비핵심 애플리케이션에 소비하는 시간을 최소화하는 것이다. 애플리케이션 팀은 애플리케이션 언어에 대한 기능 프로그래밍 기술을 갖춘 것 외에도 플랫폼 기술과 시스템 구성에 대한 이해를 가져야 한다. 이를 통해 기능 개발과 애플리케이션 강화에만 집중할 수 있다.
인프라 팀(Infrastructure Team)
인프라팀은 애플리케이션을 실행하는 데 필요한 인프라를 만들고 구성하는 코드를 작성한다. 인프라 팀은 어떤 자원이 필요한지 명시할 책임이 있으며, 애플리케이션 팀과 긴밀하게 협력한다. 인프라 팀은 소규모 앱일 경우, 한 명 또는 두 명으로만 구성될 수도 있다. 이 팀은 AWS CloudFormation, HashiCorp Terraform과 같은 인프라 프로비저닝 방법에 대한 기술을 보유해야하며, Chef, Puppet, Anible, Saltt와 같은 도구를 사용하여 구성 자동화 기술을 개발해야한다.
도구 팀(Tools Team)
도구팀은 CI/CD 파이프라인을 구축하고 관리한다. 파이프라인을 구성하는 인프라와 도구를 책임진다. 이들은 조직 내 애플리케이션 및 인프라 팀이 사용하는 도구를 만든다. 조직은 도구 팀이 애플리케이션 및 인프라 팀보다 한 발 앞서 나가도록 도구팀을 지속적으로 성숙시켜야한다.
도구 팀은 CI/CD 파이프라인의 모든 부분을 구축하고 통합하는 데 능숙해야 한다. 여기에는 소스 제어 리포지토리, 워크플로우 엔진, 빌드 환경, 테스트 프레임워크, 아티팩트 리포지토리 등이 포함된다. 몇몇 조직은 이 팀을 DevOps팀이라고 부르는데, AWS는 이것을 추천하지 않는다. AWS는 DevOps를 소프트웨어 전달에서의 사람, 프로세스, 도구들의 종합이라고 생각하도록 권장한다.
이 팀은 Jenkins, GitHub, 아티팩트 저장소, TeamCenter 등과 함께 AWS CodePipeline, AWS CodeCommit, AWS CodeDeploy, AWS CodeBuild와 같은 소프트웨어를 구현할 수 있다.
4.3. 지속적 통합 및 지속적 전달을 위한 테스트 단계
3개의 팀은 CI/CD 파이프라인의 다른 단계에서 테스팅을 소프트웨어 개발 라이프사이클에 통합해야한다. 테스트는 가능한 한 빨리 시작해야한다.
유닛테스트
유닛테스트는 피라미드의 가장 바닥에 있다. 그들은 가장 빠르게 실행될 뿐만 아니라 가장 비용이 저렴하다. 그러므로, 유닛테스트는 테스트 전략의 대부분을 차지해야한다. 좋은 경험의 법칙은 약 70%이다. 단위테스트는 이 단계에서 걸린 버그를 빠르고 저렴하게 고칠 수 있기 때문에 거의 완벽한 코드 커버리지를 가져야한다.
서비스, 컴포넌트, 통합 테스트
이 테스트 들은 단위 테스트 위에 있다. 이러한 테스트들은 세부적인 환경을 필요로 하므로 인프라 요구사항의 비용이 더 많이들고 더 느리게 실행된다.
성능, 적합성 테스트
이 테스트들은 그 다음에 있으며, 프로덕션 퀄리티의 환경을 요구하고 아직은 비용이 더 많이든다.
UI, 사용자 승인 테스트
피라미드의 가장 위에 있으며, 이 테스트 또한 프로덕션 퀄리티의 환경이 필요하다.
1. Source 설정
Source 단계에서는 Github 또는 AWS CodeCommit에서 호스트된 소스코드 리포지토리를 선택한다.
2. Build 설정 및 실행
CI 프로세스에 필요한 자동화를 구축한다. 빌드 자동화를 설정할 때 첫 번째 작업은 올바른 빌드 도구를 선택하는 것이다. 가장 잘 맞는 빌드 도구는 프로젝트의 프로그래밍 언어와 팀의 스킬 셋에 따라 달라질 것이다.
빌드도구
Java - Ant, Maven, and Gradle
C/C++ - Make
JavsScript - Grunt
Ruby - Rake
빌드 도구를 선택한 후, 빌드 스크립트에서 빌드 단계와 함께 모든 종속성을 명확하게 정의해야 한다.
최종 빌드 아티팩트를 버전화하는 것도 모범 사례로, 배치와 문제 추적이 용이하다.
Build 단계에서 빌드 도구는 소스코드 리포지토리의 변경사항을 입력하여 소프트웨어를 빌드하고 다음과 같은 유형의 테스트를 실행한다.
유닛 테스트(Unit Testing)
코드의 특정 부분을 테스트하여 코드가 예상한 대로 작동하는지 확인한다. 유닛테스트는 개발 단계에서 소프트웨어 개발자에 의해 수행된다. 이 단계에서는 정적 코드 분석, 데이터 흐름 분석, 코드 커버리지(적용 범위) 및 기타 소프트웨어 검증 프로세스를 적용할 수 있다.
정적 코드 분석(Static Code Analysis)
이 테스트는 빌드 및 단위테스트 후에, 실제 애플리케이션을 실행하지 않고 수행된다. 이 분석은 코딩 오류와 보안 구멍을 찾는데 도움이될 수 있고 코딩 가이드라인에 부합한지 확인할 수 있다.
3. Staging 단계
스테이징 단계에서는 최종 프로덕션 환경과 같은 완전한 환경이 생성되고 아래와 같은 테스트가 수행된다.
통합 테스트(Integration Testing)
소프트웨어 설계에 대비하여 컴포넌트 간의 인터페이스를 확인한다. 통합테스트는 반복적인 프로세스이며 강력한 인터페이스 및 시스템 무결성을 구축하게 해준다.
컴포넌트 테스트(Component Testing)
다양한 컴포넌트와 결과들 사이에 전달되는 메시지를 테스트한다. 이 테스트에는 아주 큰 데이터 볼륨 또는 엣지 상황, 비정상 입력이 포함될 수 있다.
시스템 테스트(System Testing)
시스템을 end-to-end로 테스트하고 소프트웨어가 비즈니스 요구사항을 충족하는지 확인한다. 여기에는 UI, API, 백엔드 로직 및 end 상태가 포함될 수 있다.
성능 테스트(Performance Testing)
특정한 워크로드 아래에서 수행될 때, 시스템의 응답성 및 안정성을 결정한다. 성능 테스트는 또한 확장성, 신뢰성, 자원 사용 같은 시스템의 다른 품질속성을 확인하는데도 사용된다. 성능 테스트는 load test, stress test, spike test를 포함할 수 있다. 성능 테스트는 미리 정의된 기준에 대한 성능이나 신뢰성을 비교하는데에 사용된다.
적합성 테스트(Compliance Testing)
코드 변경이 비기능 사양 또는 규정을 준수하는지 확인한다. 정의된 표준을 충족하게 구현되었는지 결정한다.
사용자 승인 테스트(User Acceptance Testing)
end-to-end 비즈니스 흐름을 검증한다. 이 테스트는 스테이징 환경에서 최종 사용자에 의해 수행되며, 시스템이 요구사항 명세서의 요건을 충족하는지 여부를 확인한다. 일반적으로 고객들은 알파/베타 테스트 방법론을 이 단계에서 이용한다.
4. Production 단계
이전 테스트를 통과한 후, 프로덕션 환경에서 스테이징 단계가 반복된다. 이 단계에서는 전체 배포를 하기 전에 작은 영역에만 신규 코드를 배포하여 카나리 테스트(Canary Test)를 진행할 수 있다.
4.4. 파이프라인 구축
지속적인 통합을 위한 최소 사용 가능 파이프라인부터 시작
지속적 전달은 최소 사용 가능 파이프라인(minimum viable pipeline, MVP)로 시작될 수 있다. 이런 간단한 환경을 구성하기 위한 핵심은 지속적 전달 오케스트레이션 도구인데, Amazon의 AWS CodeStar를 사용할 수 있다. AWS CodeStar는 통합 설치 프로세스, 도구, 템플릿, 대시보드와 함께 AWS CodePipeline, AWS Codebuild, AWS CodeCommit, AWS CodeDeploy를 사용한다. AWS CodeStar는 AWS에 애플리케이션을 빠르게 개발, 구축 및 배치하는 데 필요한 모든 것을 제공하여 코드를 더 빨리 릴리스할 수 있게 한다.
AWS CodePipeline의 경우 소스 단계에서 GitHub, AWS CodeCommit 및 Amazon Simple Storage Service(S3)의 입력을 수용할 수 있다. 빌드 프로세스를 자동화하는 것은 지속적인 전달을 구현하고 지속적인 배포로 가기 위한 중요한 첫 번째 단계다. 빌드 아티팩트를 제작하는 과정에서 사람이 개입하지 않게 되면 팀원들의 부담이 없어지고, 수동 패키징에 의해 발생하는 오류를 최소화하고, 소모성 패키징 아티팩트를 더 자주 시작할 수 있다.
지속적 전달 파이프라인
지속적인 통합 파이프라인이 구현되고 프로세스가 수립된 후, 귀사의 팀은 지속적인 전달 파이프라인으로의 전환을 시작할 수 있다. 팀은 애플리케이션 구축과 배포를 모두 자동화해야 한다.
지속적인 전달 파이프라인은 스테이징과 프로덕션 단계가 있는 것이 특징이며, 프로덕션 단계는 수동 승인 후에 실행된다.
Continuous Integration 파이프라인이 구축된 방식과 동일한 방식으로, 팀은 배포 스크립트를 작성하여 점진적으로 Continuous Delivery 파이프라인을 구축할 수 있다.
AWS CodePipeline은 사내에서 실행되는 Amazon EC2 인스턴스 및 인스턴스에 대한 코드 배포를 자동화하는 서비스인 AWS CodeDeploy, Chef를 사용하여 애플리케이션 운영을 돕는 구성 관리 서비스인 AWS OpsWorks, 웹 애플리케이션 배포 및 확장 서비스인 AWS Elastic Bestalk와 직접 통합된다.
Lambda Action 추가
AWS CodeStar 및 AWS CodePipeline은 AWS Lambda와의 통합을 지원한다. 람다 함수는 CI/CD 파이프라인에서 다음 작업을 수행할 수 있다.
- AWS CloudFormation 템플릿을 적용하거나 업데이트하여 환경에 대한 변경을 롤아웃하십시오.
- AWS CloudFormation을 사용하여 파이프라인의 한 단계에서 필요에 따라 리소스를 생성하고 다른 단계에서 삭제하십시오.
- CNAME 값을 변경하는 람다 기능이 있는 AWS Elastic Beanstalk에 다운타임 없이 애플리케이션 버전을 배포하십시오.
- ECS(Amazon EC2 Container Service) 도커 인스턴스에 배포하십시오.
- AMI 스냅샷을 생성하거나 배포하기 전에 리소스를 백업하십시오.
- IRC 클라이언트에 메시지를 게시하는 등 타사 제품과의 통합을 파이프라인에 추가하십시오.
수동 승인
필요한 IAM(AWS Identity and Access Management) 권한을 가진 사용자가 작업을 승인하거나 거부할 수 있도록 파이프라인 실행을 중지할 지점의 단계에 승인 작업을 추가하십시오. 작업이 승인되면 파이프라인 실행이 재개된다. 조치가 거부되거나, 작용에 도달하여 정지한 지 7일 이내에 아무도 조치를 승인하거나 거부하지 않는 경우, 그 결과는 액션이 실패하는 것과 같으며, 파이프라인 실행이 계속되지 않는다.
CI/CD 파이프라인에서 인프라 코드 변경사항 배포
AWS CodePipeline을 사용하면 파이프라인의 모든 단계에서 배포 작업으로 AWS CloudFormation을 선택할 수 있다. AWS CloudFormation은 인프라스트럭처를 코드로 프로비저닝하는 여러 가지 방법이 있지만, AWS에서 가장 포괄적인 AWS 리소스 세트를 코드로 설명할 수 있는 확장 가능하고 완벽한 솔루션으로 추천하는 포괄적인 툴이다. AWS CodePipeline 프로젝트에서 AWS CloudFormation을 사용하여 인프라 변경 및 테스트를 추적할 것을 권장한다.
서버리스 애플리케이션을 위한 CI/CD
서버가 없는 애플리케이션 개발자인 경우 AWS CodePipeline, AWS CodeBuild, AWS CloudFormation의 조합을 사용하여 AWS Serverless Application Model로 구축된 템플릿으로 표현되는 서버 없는 애플리케이션의 구축, 테스트 및 구축을 자동화할 수 있다.
여러 팀, 지사, 지역의 파이프라인
여러 팀이 단일 코드 저장소를 사용할 경우 각 팀이 자체 분기를 갖도록 매핑할 수 있고, 프로젝트 최종 합병을 위한 통합 또는 릴리스 분기가 있어야 한다.
단일 파이프라인을 사용할 경우 한 팀이 파이프라인을 차단하여 다른 팀의 진행에 영향을 줄 수 있다. 팀 지사에 대한 특정 파이프라인과 최종 제품 전달을 위한 다른 릴리스 파이프라인을 만들 것을 권장한다.
5. 배포 방법의 종류
새로운 버전의 소프트웨어를 롤아웃하기 위해 여러 배포 전략을 고려할 수 있다. 이번 섹션에서는 가장 일반적인 배치 방법에 대해 논의한다.
1. 한 번에 모두 배포(All at Once, In-Place Deployment)
이 배포방법은 기존에 존재하는 서버들에 새로운 애플리케이션 코드를 roll out(출시)하는 방법이다. 이 방법은 한번의 배포로 모든 코드를 대체시키고, 한번에 모든 서버가 업데이트되기 때문에 다운타임이 발생한다. 또한, 배포가 실패할 경우 운영을 복원하는 유일한 방법은 모든 서버에 코드를 다시 배포하는 것이다.
2. 롤링 배포(Rolling Deployment)
롤링 배포는 모든 서버가 한번에 업데이트되지 않도록 서버를 일부분씩 나눠서 배포하는 방법이다. 배포가 진행되는 동안 새 버전과 구 버전이 동일한 서버에서 실행된다. 이 방법은 다운타임이 없고, 배포에 실패할 경우에도 오직 업데이트된 일부분에만 영향을 미치게된다.
◽ 카나리 배포(Canary Release)
롤링 배포의 변형 중 한가지로 카나리 배포가 있다. 카나리 배포는 처음에는 새 소프트웨어 버전을 서버의 아주 작은 비율만큼만 배포하는 배포 방법이다. 몇 대의 서버에만 배포를하기 때문에, 오류가 있는 변경사항의 영향을 최소화하면서도 소프트웨어가 잘 동작하는지 관찰할 수 있다. 카나리 배포 후에 오류 발생률이 높을 경우 롤백이되고, 그렇지 않을 경우 새 버전의 서버 비율을 점차 늘려가면 된다.
3. 불변형 배포(Immutable Deployment)
불변형 배포는 완전히 새로운 서버의 셋트를 시작하여 새로운 구성 또는 버전의 코드를 배포하는 방식이다. 이 패턴은 단순한 API 호출만으로 새로운 서버 리소스를 생성할 수 있는 클라우드의 기능이 활용된다.
◽ Blue/Green Deployment
블루/그린 배포 전략은 불변형 배포의 한 종류로, 이 배포 또한 새로운 환경이 생성되어야한다. 새로운 환경이 구성되고 모든 테스트를 통과하면 트래픽을 새로운 환경으로 이동시킨다. 오래된 버전인 블루 환경은 롤백이 필요할 때 까지 유휴상태로 유지된다.
위의 배치 방법들은 AWS CodeDeploy와 AWS Elastic Beanstalk에 의해 지원되고 있다.
출처
