애플리케이션 개발을 위한 CI/CD 워크플로 구현이 점점 대중화되고 있습니다. 그러나 동시에 CI/CD를 확장하고 최적화하는 것은 어려운 일입니다.
오늘 우리는 이 과제가 무엇인지 논의하고 CI/CD를 확장하고 최적화할 수 있는 방법을 정확히 탐색할 것입니다. 자, 따라해보세요!
오늘날 애플리케이션 개발은 일반적으로 여러 개발자로 구성된 팀에서 수행됩니다. 각 개인이나 팀은 각자 맡은 역할을 수행하여 프로젝트에서 각자의 역할을 수행합니다.
그런 다음 컴파일할 여러 코드 조각이 있는 프로젝트의 끝 부분에 있습니다. 모든 사람의 작업 방식에 따라 이 통합을 관리하는 데 많은 시간이 낭비될 수 있습니다.
CI/CD, 지속적 통합 및 지속적 전달/배포는 이 문제에 대한 솔루션이며 불필요한 지연 및 충돌 없이 업데이트가 릴리스되도록 합니다. 이 과정을 이해합시다.
목차
지속적인 통합
CI 또는 지속적 통합은 프로젝트의 공유 분기에 코드 변경 사항 및 추가 사항을 지속적으로 게시하기 위한 프로세스를 함께 그룹화합니다. 이를 통해 코드를 테스트하고 실시간으로 개선 및 변경을 수행할 수 있습니다. 목표는 테스트 생성을 통해 각 요소를 테스트하는 것입니다.
이 영구적인 조치는 결국 한 블록의 모든 것을 확인하지 않고 너무 많은 요소를 동시에 작업하는 것을 방지할 수 있습니다. 따라서 단위 테스트를 수행하는 것은 이를 보장하는 데 매우 유용합니다. 따라서 코드가 잘 컴파일되고 회귀를 생성하지 않도록 하여 오류를 더 쉽게 감지할 수 있습니다.
지속적 전달
지속적 전달 또는 CD는 컨테이너에 번들로 제공되고 프로덕션에 투입될 수 있는 지속적인 통합 및 테스트를 함께 제공합니다. 즉, 이러한 코드와 수행된 테스트를 수집하고 자동화를 통해 프로덕션에 넣습니다.
인간의 행동이 필요하더라도 “방송”에 완료된 모든 것을 통합적이고 완전한 방식으로 배치함으로써 자동화됩니다. 구체적으로, 우리의 애플리케이션은 지속적인 배포를 통해 언제라도 생산에 투입될 수 있도록 개발되었습니다.
지속적인 배포
지속적 배포와 지속적 배포의 개념은 유사하지만 차이점이 있습니다. 목적이 동일하다면, 즉 프로덕션 환경에 애플리케이션을 배포하는 경우 이를 달성하기 위한 수단이 다릅니다. 지속적인 배포와 지속적인 배포를 구분하는 것은 릴리스입니다.
실제로 지속적인 배포를 통해 파이프라인의 여러 단계를 가로지르는 각 수정 사항을 직접 배포할 수 있습니다. 지속적 배포 중에 배포를 수행하려면 사람의 검증 단계가 필요합니다.
CI/CD 확장
마이크로 서비스의 수가 증가하면 CI/CD를 확장하는 것이 거의 불가피해집니다. 마이크로 서비스 수가 증가하면 여러 파이프라인이 단일 git 리포지토리에 연결되어 CI 서버의 부하가 증가하고 성능이 저하됩니다.
CI/CD를 확장하려면 모든 팀을 위한 표준화되고 자동화된 개발 파이프라인을 만들고 여기에서 개별 개발자 제공 및 팀 제공의 품질을 보장해야 합니다. 또한 파이프라인을 쉽게 관리할 수 있습니다.
단위 테스트를 실행하고 전달된 코드의 품질을 검증하기 위한 CI 프로세스를 정의하여 확장을 수행할 수 있습니다.
이미지를 빌드하고 환경에 지속적으로 배포하는 CD 프로세스가 이어지며 마지막으로 이미지를 빌드하고 프로덕션 환경에 배포하는 프로세스를 정의합니다.
CI/CD 확장 단계
첫 번째 단계는 파이프라인을 팀 리더와 함께 설계자와 조정하는 것입니다. 환경에 대한 Git 분기의 매핑을 따릅니다(개발 -> 개발 및 마스터 -> [homologation and production]). 그런 다음 각 풀 요청에서 CI 작업이 실행되고 매핑된 분기가 변경될 때마다 CD 작업이 실행됩니다.
추적할 CI 및 CD 모두에 대해 작업 스트림을 생성할 수 있습니다.
CI 작업 흐름은 7단계로 진행됩니다.
- 풀 리퀘스트 소스와 대상 브랜치를 확인하세요.
- 병합에 수동 해결이 필요한 충돌이 없는지 확인합니다.
- 단위 테스트를 실행합니다.
- 무결성을 확인하고 코드를 컴파일할 수 있는지 확인하기 위해 패키지를 빌드합니다.
- 트리거 코드 품질 검증
- 프로젝트 버전을 소스 브랜치로 늘리고 커밋합니다.
- Webhook 또는 Rest API 호출(Git Repository)을 통해 Pull Request Git 저장소에 성공 또는 실패를 알립니다.
CD 작업 흐름은 다음 경로를 따릅니다.
- 통지된 분기가 체크아웃됩니다.
- 아티팩트는 작업 중인 프로젝트의 특정 빌드 도구를 사용하여 빌드됩니다.
- 아티팩트가 도착한 후 라이브러리 프로젝트는 아티팩트의 저장을 위해 Nexus로 전송되고 흐름이 완료됩니다.
다음 작업이 수행됩니다.
1단계: 생성된 아티팩트에 대한 Docker 이미지가 생성되어 아티팩트 버전을 Docker 이미지에 적용합니다.
2단계: 이미지가 Docker 레지스트리에 업로드됩니다.
3단계: Kubernetes를 통한 이미지 롤아웃을 통한 배포.
승인/프로덕션 환경에 있는 애플리케이션 프로젝트의 경우 위의 1단계와 2단계를 수행한 후 다음을 수행합니다.
- 승인 환경에서 Kubernetes를 통해 이미지 롤아웃을 통해 배포합니다.
- 롤아웃이 프로덕션용으로 승인될 때까지 작업이 잠시 중단됩니다.
- 승인되면 승인 중인 이미지가 프로덕션용으로 승격됩니다.
- 그렇지 않으면 승인 시 이미지를 롤백합니다.
CI/CD 최적화
CI/CD는 애플리케이션 개발 주기를 개선하고 새로운 코드를 통합하고 전달 빈도를 높여 발생하는 문제를 해결합니다.
다음은 CI/CD 사용을 더욱 최적화할 수 있는 방법입니다.
손상된 빌드 수정 우선 순위
빌드가 고장나면 수정하는 것이 팀의 우선 순위가 되어야 합니다. 몇 분 안에 빌드를 수정할 수 없는 경우 팀은 코드를 제거할지 아니면 기능 플래그를 비활성화할지 결정해야 합니다.
깨진 빌드를 수정하는 이면에 있는 아이디어는 빌드가 항상 릴리스될 수 있는 작업 코드를 생성한다는 것입니다.
소규모 자주 배포
일반적으로 배포가 발생할 때마다 애플리케이션의 안정성이 위험에 노출됩니다. 따라서 우리는 배포를 서로 거리를 두는 경향이 있습니다. 이 접근 방식의 문제는 너무 많은 변경 사항을 누적한다는 것입니다. 이러한 변경 사항 중 하나가 잘못되어 작동하던 다른 변경 사항을 롤백해야 할 수 있습니다.
스트랭글러 패턴을 적용하고 복잡한 변경 사항을 작고 간단한 변경 사항으로 나눕니다. 더 자주 배포하고 소규모 배치로 작업하면 배포 위험이 낮아집니다.
위험 완화를 위한 QA 테스트 자동화
로컬 개발 환경이 종종 다르기 때문에 우리 모두는 “내 로컬 컴퓨터에서 작업” 시나리오에 관여했을 것입니다. 로컬 환경과 프로덕션 환경 사이에는 여러 가지가 있을 수 있습니다. 브라우저 테스트와 같은 품질 보증(QA) 작업을 자동화하여 CI/CD를 최적화하고 버그가 라이브 애플리케이션에 도달할 위험을 완화할 수 있습니다.
자동화된 테스트 신뢰
개발자가 새 코드를 통합할 때 유효성을 검사하기 위해 CI는 자동화되고 안정적인 테스트 제품군에 의존합니다. 코드를 컴파일해야 하는 경우 첫 번째 테스트는 컴파일하는 것입니다. 그런 다음 중요하다고 생각하는 만큼 테스트를 추가할 수 있습니다.
얼마나 많은 테스트를 포함해야 합니까? 이를 결정하기 위해 CI의 목표는 가능한 한 빨리 피드백을 제공하는 것임을 기억하십시오. 개발자가 피드백을 받기 위해 한 시간을 기다려야 하는 경우 작동하지 않습니다. 항상 놓치는 부분이 있지만 프로덕션에서 버그를 발견하면 테스트 케이스를 만들어 CI 루프에 포함시키십시오.
항상 보안을 고려하십시오
기존 구성 또는 환경에 통합되는 CI/CD 도구의 보안을 고려하십시오. CI/CD에서는 모든 보안 테스트 도구를 프로그래밍 방식으로 호출하고 그 결과를 한 곳에서 집계해야 합니다. 자동화된 암호화 감사를 위한 API가 있는 도구를 찾으십시오.
CI/CD 확장 및 최적화의 이점
개발 팀의 효율성을 높이는 것 외에도 CI/CD를 확장하고 최적화하면 다음과 같은 다른 이점도 있습니다.
오버헤드 감소
개발 시간은 일반적으로 청구 가능하지만 코드 또는 파일을 수동으로 배포하는 데 소요되는 시간은 어떻습니까? 흐름의 많은 부분을 자동화하면 모든 사람이 감사할 수 있는 청구 가능한 작업 시간을 절약할 수 있습니다. 또한 자동화된 테스트를 통해 QA 또는 프로덕션에서 오류를 찾는 것보다 더 빨리 실패하거나 고객이 오류를 발견할 수 있습니다. 같은 시간에 더 많은 버그를 수정하는 것이 확실한 승리입니다.
더 적은 버그와 더 적은 위험으로 제공
사소한 변경 사항을 더 자주 릴리스하여 개발 프로세스에서 훨씬 더 일찍 버그를 잡을 수 있습니다. 개발의 모든 단계에서 자동화된 테스트를 구현하면 실패한 코드를 다음 단계로 옮길 위험이 없으며 필요할 때 사소한 변경 사항을 롤백하기가 더 쉽습니다.
시장 상황에 더 빠르게 대응
시장 상황은 끊임없이 변화합니다. 새 제품으로 인해 수익이 감소하거나 노트북보다 스마트폰에서 사이트에 액세스하는 고객이 더 많다고 가정해 보겠습니다. 이 경우 지속적 전달을 최적화하면 빠른 변경이 훨씬 쉽습니다.
신뢰
CI/CD를 최적화했다면, 즉 강력한 테스트 스위트가 있다는 의미이며, 버그를 제출하지 않는다는 자신감이 크게 높아집니다. 프로세스를 투명하게 공개하고 나머지 팀과 고객을 교육하면 개발 팀으로서 귀하에 대한 신뢰도 높아집니다.
마지막 단어
CI/CD를 사용하면 통합 및 제공 속도가 빨라집니다. 그러나 복잡성 증가로 인해 프로세스가 비생산적으로 되지 않도록 확장하고 최적화하는 것이 중요합니다.
최고의 CI 도구를 살펴볼 수도 있습니다.