DevOps에서 빌드 자동화란 무엇인가요?
자동화 빌드는 지속적 통합(CI) 자동화에서 중추적인 역할을 하고 CI/CD 파이프라인의 핵심 요소입니다. 이러한 빌드는 최신 변경 사항으로 인해 코드에서 이슈가 발생하는 경우 이를 가능한 한 신속히 알리도록 설계된 일련의 자동화된 단계 중 첫 번째 단계입니다.
이 컨텍스트에서 빌드에 대해 이야기할 때는 단순히 소스 코드를 컴파일하고 연결하여 실행 파일을 생성하는 것 이상을 의미합니다.
자동화 빌드 프로세스에는 프로그램을 실행하는 데 필요한 모든 코드의 확인은 물론이고 일련의 점검이 포함됩니다. 번역된 언어로 작업하는 경우에도 빌드 단계가 필요합니다.
빌드 아티팩트라고도 하는 빌드 단계의 파일 출력은 테스트에 이어 스테이징의 추가 단계를 위해 CI/CD 파이프라인을 통해 진행됩니다. 빌드가 파이프라인의 모든 단계를 통과하면 라이브 릴리스 준비가 된 것입니다.
빌드 및 배포 프로세스를 자동화하는 이유는 무엇인가요?
빌드 자동화가 무엇을 포함하는지 살펴보기 전에 자동화된 빌드 관리 프로세스가 왜 중요한지 생각해 보겠습니다.
IDE에서 작업하는 경우 일반적으로 키보드 단축키로 빌드를 트리거할 수 있는데, 왜 프로세스를 자동화하나요?
우선, 로컬 빌드는 업무의 온전성 검사를 하거나 상사에게 뭔가를 빠르게 시연하고 싶을 때 편리하지만, CI/CD 파이프라인에 로컬 빌드를 사용하는 것은 좋지 않습니다.
전용 빌드 서버를 사용하면 깨끗한 환경이 보장되어 누락된 종속성이 곧 표시되며 그렇지 않으면 출력이 테스트 환경에 배포될 때 이슈 및 지연의 원인이 될 수 있습니다.
파이프라인의 다른 단계를 시작하는 자동화된 빌드가 없다면 CI/CD의 안정성이 훨씬 떨어집니다. 빌드 서버에 로그인하여 테스트를 포함한 각 빌드를 시작하고, 빌드가 실패할 경우를 대비하여 이 프로세스를 지켜봐야 하며, 결과물을 테스트에 배포될 수 있도록 아티팩트 저장소로 이동해야 한다면, 그 과정에서 오류가 발생하기 쉽습니다.
테스트를 몇 번 더 변경할 때까지 빌드 시작을 연기하는 것은 쉽지만, 그렇게 하면 CI/CD의 이점이 저하됩니다.
마지막으로 CI/CD 파이프라인의 기본 전략은 페일 패스트하는 것입니다.
문제를 빨리 확인할수록 더 쉽게 해결할 수 있고 빌드 자동화 프로세스의 효율성도 높아집니다. 빌드 단계를 자동화하면 관련된 다양한 단계를 수동으로 트리거하는 것보다 빠르고 파일을 옮기거나 테스트를 수동으로 실행하는 것보다 훨씬 빠릅니다.
빌드를 자동화하면 모든 단계가 단일 커밋(또는 커밋 배치에서)에서 올바른 순서로 수행되고 시간을 절약하는 동시에 빠른 피드백의 이점을 누릴 수 있습니다.
CI/CD 파이프라인에서 빌드 자동화는 어떻게 작동하나요?
CI/CD를 처음 사용하는 경우 자동화된 빌드를 설정하고 팀의 누군가가 변경 사항을 커밋할 때마다 이를 트리거하는 것이 가장 먼저 해야 할 일 중 하나입니다(모든 것을 소스 관리 시스템으로 통합한 후). IDE에서 제공하거나 직접 작성한 빌드 스크립트 또는 정의 파일이 이미 있을 수 있습니다.
그렇지 않으면 현재 작업 중인 언어에 적합한 빌드 자동화 도구를 선택하고 컴파일, 링크 및 패키징할 파일을 지정해야 합니다. 그런 다음 CI 서버를 사용하여 초기 트리거부터 피드백 제공, 실패 조건 정의에 이르기까지 다양한 단계를 조율할 수 있습니다.
빌드 트리거
자동화된 지속적 통합에는 마스터에 대한 각 커밋 후 빌드를 트리거하여 모든 변경 사항이 통합된 직후 테스트를 거칩니다. 빌드가 성공적으로 완료되면 프로세스의 다음 단계를 트리거합니다.
대부분의 CI 도구를 사용하면 빌드에 대한 추가 트리거를 구성하고 이후의 파이프라인 단계를 사용자 지정할 수 있습니다.
예를 들어 특정 디렉터리의 브랜치에 커밋이 수행될 때 동일한 단계 집합을 트리거해야 합니다. 반면에 배포 도구의 도움으로 추가 테스트 계층을 거쳐 스테이징 환경을 새로 고침하는 데 사용되는 야간 빌드를 예약해야 할 수 있습니다. 빌드 단계를 수동으로 시작할 수도 있습니다.
빌드 실행
빌드 단계는 개발 시스템보다는 전용 빌드 서버에서 실행하는 것이 좋습니다. 깨끗한 환경에서 빌드하면 누락된 종속성이 모두 표시되며 "하지만 내 시스템에서 작동"과 같은 유사한 이슈를 방지할 수 있습니다.
빌드 단계 자체는 선택한 빌드 자동화 도구(예: Maven, Ant 또는 Gradle)를 호출하여 빌드 스크립트 또는 정의 파일에 지정된 작업을 실행합니다.
빌드를 실행하는 데 시간이 얼마나 걸리는지 파악했으면 배포 도구를 사용하여 지정된 기간 내에 완료되지 않는 빌드에 대해 실패 조건을 구성하는 것이 좋습니다. 이렇게 하면 장시간 실행하는 빌드가 리소스를 차단하는 것을 방지할 수 있습니다.
테스트 실행
자동화된 빌드 관리 프로세스는 배포를 위해 코드를 준비할 뿐 아니라 유닛 테스트, 린팅 및 정적 코드 분석과 같은 코드에 대한 기타 여러 가지 검사를 실행할 수 있는 최적의 단계입니다. 배포 도구의 도움으로 이러한 검사를 모든 빌드의 일부로 실행하고 문제가 발생할 때 이를 해결하면 코드 품질을 개선하는 데 도움이 됩니다.
이러한 검사는 빌드 아티팩트가 생성되기 전에 실행되지만 장애가 발생하더라도 나머지 파이프라인을 중단할 필요는 없습니다. 예를 들어 린팅 오류가 발견된 경우에도 빌드 아티팩트를 게시하고 다음 파이프 라인 단계로 진행하기로 결정할 수 있습니다. 품질 임곗값을 구성하면 "작은" 이슈가 시간이 지남에 따라 누적되는 것을 방지할 수 있습니다.
빌드 아티팩트 게시
자동화된 빌드 프로세스의 출력은 설치 프로그램, WAR 파일, 라이브러리 및 컨테이너를 포함할 수 있는 빌드 아티팩트입니다. 이러한 파일을 아티팩트 저장소에 게시하면 배포 도구의 도움으로 다양한 환경에 빌드를 배포할 수 있는 중앙 위치를 확보할 수 있습니다.
빌드 후 CI/CD 파이프라인의 다음 단계에는 일반적으로 하나 이상의 테스트 환경(때로는 데이터베이스 또는 기타 마이크로서비스와 같은 다른 구성 요소와 함께)에 빌드를 배포해야 하는 자동화된 기능 테스트가 포함됩니다. 이러한 테스트가 성공적으로 완료되면 스테이징 환경을 새로 고침하는 데 동일한 빌드를 사용할 수 있으며, 최종적으로 라이브 릴리스할 수 있습니다.
메트릭 및 피드백
빌드가 성공적으로 생성되었는지 여부, 유닛 테스트 및 기타 검사 결과를 포함하여 빌드 단계의 결과를 CI 도구에서 볼 수 있습니다. 장애를 알리도록 알림을 구성하면 신속하게 대응하여 코드를 다시 릴리스 가능한 상태로 되돌릴 수 있습니다.
또한 배포 도구는 트렌드를 분석할 수 있도록 파이프라인에서 데이터를 분류합니다. 빌드 시간, 성공률 및 코드 커버리지와 같은 지표와 빌드 기록을 검토하면 CI/CD 프로세스를 개선하는 데 도움이 되는 인사이트를 얻을 수 있습니다.