지속적 통합

이 페이지에서는 지속적 통합에 대해 알아야 할 모든 사항을 안내합니다. 지속적 통합, 지속적 배포, 지속적 전달 간의 미묘한 차이를 알아보고 소프트웨어의 빌드 및 테스트를 자동화하기 위한 사용 사례와 모범 사례를 설명합니다.

지속적 통합(CI)이란 무엇인가요?

지속적 통합(CI)이란 팀에서 배포하는 코드의 품질을 보장하는 동시에 개발 속도를 높일 수 있는 소프트웨어 개발 전략입니다. 개발자는 코드를 매일 한 차례 이상 조금씩 커밋하며, 이 코드는 공유 리포지토리와 병합되기 전에 자동으로 빌드 및 테스트됩니다.

지속적 통합: 개요

• 모든 개발자가 공유된 주요 코드 리포지토리에 매일 또는 더 자주 커밋합니다.
• 모든 커밋은 코드베이스의 자동화된 빌드 및 테스트를 트리거합니다.
• 빌드 또는 테스트에 실패하면 신속하게(대개 몇 분 내에) 복구됩니다.

지속적 통합은 애자일 방법론을 적용하면 효과적입니다. 팀 구성원은 증가하는 ‘스토리’ 작업을 수행하며 이러한 소프트웨어 코드의 변경 사항은 하루에 여러 번 공유 소프트웨어 리포지토리에 점차적으로 병합됩니다.

지속적 통합은 다양한 유형의 소프트웨어 프로젝트에 사용될 수 있습니다. 예를 들어 당사는 CircleCI 웹사이트를 업데이트하기 위해 지속적 통합을 사용합니다.

1. 개발자 또는 콘텐츠 게시자가 GitHub에 새 코드 브랜치를 만들고 페이지의 HTML을 업데이트한 다음 변경 사항을 커밋합니다.

2. 개발자가 특정 브랜치에서 모든 변경 사항을 완료하면 GitHub에 풀 요청을 생성합니다.

3. GitHub는 CircleCI와 통합됩니다. CircleCI는 코드에서 빌드 프로세스를 실행한 다음 자동화된 테스트 스크립트를 실행합니다.

4. CircleCI에 오류가 발생하면(빌드 상태 빨간색) 개발자에게 이메일로 통보됩니다.

5. 그렇지 않으면 빌드가 성공했다는 알림(녹색)이 표시되고 코드가 준비 서버로 푸시되었다는 알림이 표시됩니다. 이렇게 하여 개발자가 웹 페이지를 미리 볼 수 있습니다.

6. 확인되면 개발자는 새 코드 브랜치를 프로덕션으로 병합할 수 있습니다.

지속적 통합, 지속적 전달, 지속적 배포의 차이점은 무엇인가요?

지속적 통합

새로운 커밋마다 자동으로 애플리케이션을 빌드 및 테스트합니다.

지속적 전달

항상 애플리케이션을 배포할 준비가 된 상태입니다. 실제로 애플리케이션을 배포하려면 수동 단계가 필요합니다.

지속적 배포

빌드, 테스트, 배포를 자동화합니다. 모든 테스트를 통과하면 새로운 모든 커밋이 수동 개입 없이 전체 개발 파이프라인을 통해 새 코드를 프로덕션으로 푸시합니다.

관련 게시물:

지속적 전달 작성자: Martin Fowler
지속적 전달과 지속적 배포의 비교 작성자: Jez Humble
지속적 배포 작성자: Timothy Fitz
지속적 전달 작성자: Wikipedia
지속적 통합이란? 작성자: Lev Lazinskiy
지속적 배포란? 작성자: Laura Franzese
DevOps의 간략한 역사, 3부: 자동화된 테스트 및 지속적 통합 작성자: Alek Sharma
DevOps의 간략한 역사, 4부: 지속적 전달과 지속적 배포 작성자: Alek Sharma

지속적 통합(CI)과 지속적 배포(CD)의 비교

지속적 통합은 소프트웨어의 빌드 및 테스트를 자동화합니다. 지속적 배포는 이러한 자동화의 확장으로 일련의 테스트를 통과하는 모든 코드 커밋 후에 소프트웨어를 배포할 수 있게 합니다. 가장 성공적인 개발팀은 소프트웨어를 자주 배포합니다.

소프트웨어 개발 프로세스는 다음과 같은 세 가지 주요 작업으로 구성됩니다.

1. 코드 생성: 소프트웨어 개발팀이 가장 창의력을 발휘하는 부분입니다. 이들은 사용자 스토리를 멋진 코드로 변환합니다.

2. 소프트웨어로서의 새 코드 오케스트레이션: 지속적 통합에서 핵심적인 부분입니다. 개발자가 코드를 커밋하면 지속적 통합의 빌드 서버가 빌드, 테스트, 배포 프로세스를 자동화합니다.

3. 물류: 새 소프트웨어를 프로덕션으로 배송하는 마지막 단계입니다. 프로세스 중 이 부분의 도구는 프로덕션 단계의 소프트웨어를 모니터링 및 관리합니다.

생성 프로세스에서 가장 중요한 도구는 코드를 보관하기 위해 사용되는 리포지토리입니다. CircleCI는 GitHub 및 Bitbucket과 통합됩니다. 서버 솔루션 역시 GitHub Enterprise와 통합됩니다.

CircleCI는 작업 오케스트레이션 중심에 있습니다. 이는 코드는 작업 소프트웨어로 변환하는 힘든 작업을 수행합니다. 사용자는 YAML 파일을 통해 코드가 처리되는 방식을 구성합니다. YAML 파일을 사용하면 코드를 통해 구성하고 거의 무한대로 구성 가능하기 때문에 팀이 원하는 방식으로 빌드하고 테스트할 수 있습니다.

소프트웨어 개발 프로세스의 물류 부분에는 테스트를 거쳐 검증된 코드를 프로덕션으로 전환하는 것이 포함됩니다. 여기에는 프로덕션 서버의 설정, 구성, 관리가 포함됩니다. 지속적 통합의 모든 이점을 활용하려면 지속적 배포가 필요합니다.

CI/CD를 시작하는 방법

애플리케이션 개발 과정에서 최대한 빠르게 지속적 통합(CI) 파이프라인을 설정하는 것이 중요합니다. CI 파이프라인에 테스트가 추가되면 확신을 갖고 지속적으로 혁신하고 빌드할 수 있습니다. 테스트를 통과하지 못한 주요 코드에 코드를 병합할 수 없다는 것을 알기 때문입니다. 또한 지속적인 배포 워크플로를 CI 파이프라인으로 발전시키면 배포가 자동화됩니다. CircleCI를 사용하면 소프트웨어의 빌드, 테스트, 배포를 자동화할 수 있으며 엔지니어는 사용자가 가장 중요하게 생각하는 기능을 빌드하는 데 다시 힘을 쏟을 수 있습니다.

시작하기

1. 새 CI/CD 도구를 도입하여 달성하고자 하는 목표와 관련하여 모두가 같은 내용을 이해할 수 있도록 하세요.

2. 항상 작은 것부터 시작하세요. 조직 전체를 하루아침에 모범적인 DevOps 팀으로 만들려고 하지 마세요. 대신 한 팀에서 프로세스를 변경하여 조직 내에서 효과적인지 확인해야 합니다. 개선되는 상황이 보인다면 점진적으로 밀고 추진하세요.

3. 자신에게 맞는 솔루션을 채택하세요. DevOps가 자신의 조직에 적합한 솔루션이 아닐 수도 있다는 점을 이해해야 합니다. 일부 회사에서는 DevOps 없이도 장기간 성공을 거두었으며, 그들의 문화나 제품 요구 사항을 고려할 때 DevOps는 맞지 않을 수 있습니다. 예를 들어 회사의 제품 전략에서 기밀성이 큰 부분을 차지하는 경우 대규모 출시 전까지 모든 제품 세부 사항을 비밀에 부쳐야 하므로 피드백을 얻기 위해 점진적으로 배송하는 것은 효과가 없습니다. 이러한 환경에서는 DevOps 문화를 구축하기가 매우 어려울 것입니다.

4. 항상 측정하세요. 개선 계획을 시작하기 전에 현재 당면한 문제(예: 개발 주기에 X만큼의 시간이 걸림)에 대한 정확한 지표를 얻어야 합니다. 이 조치는 사이트 안정성 엔지니어를 개발팀에 초대하기 전에 수행하세요. 시간이 조금 지나면 효과가 있었는지 확인할 수 있게 됩니다. 예를 들어 수많은 애자일 전환 시도와 함께 많은 회사들이 구체적인 이유를 파악하거나, 팀에 긍정적인 효과를 주는지 측정해보지도 않고 스탠드업 미팅을 도입했습니다. 그렇다면 절약한 시간보다 허비한 시간이 더 많을 것입니다.

5. 모든 것을 자동화하려고 하지 마세요. 적어도 모든 걸 동시에 하려고 하지 마세요. DevOps에 대한 오해 중 하나는 모든 인프라 프로비저닝 및 구성 관리를 자동으로 수행해야 한다는 것입니다. 이를 ‘코드로서의 인프라’라고 합니다. 그러나 수동으로 처리할 때 더 효과적인 작업도 있습니다. 자동화가 모두를 위한 솔루션은 아닙니다. 때로는 자동화를 위한 최적의 솔루션이 무엇인지 알아보기 위해 수동적인 방법을 시작해야 할 수도 있습니다.

지속적 통합은 새로운 도구를 구현하는 것만이 아닙니다. 이는 개발팀의 업무 방식을 바꾸는 것입니다. 그리고 새로운 사고방식입니다. 조직 문화를 바꾸는 것은 쉽지 않습니다. 지속적 통합을 시작하는 가장 좋은 방법은 작은 것부터 시작하는 것입니다.

예정된 소규모 프로젝트를 개념 증명으로 사용하여 다음과 같은 기본 사항을 파악하세요.

• 엄격한 테스트 방식(자동화된 테스트 사용 권장)
• 테스트부터 프로덕션까지 지속적인 소프트웨어 환경
• 지속적 통합 방식에 관한 교육
• 주요 지표를 측정하기 위한 보고서

팀이 정기적으로 조금씩 커밋하기 시작하면 버그에 대응하는 것이 얼마나 쉬운지 알게 될 것입니다. 또한 버그를 더 빠르게 해결할수록 기능을 훨씬 더 빠르게 제공할 수 있습니다. 이를 통해 팀은 조직 전체에 걸쳐 지속적 통합을 확장할 수 있는 동력을 얻을 수 있습니다.

지속적 통합 및 지속적 배포(CI/CD)를 위한 최고의 도구는 무엇인가요?

DevOps는 개발자와 운영팀 간의 매우 특별한 협업입니다. 이는 본질적으로 인프라에는 개발 방식을, 개발 주기에는 운영 방식을 문화적으로 채택했다는 의미입니다. 실제로는 어떤 모습일까요? 인프라를 코드로 유지하거나, 언제든지 분해할 수 있도록 재사용 가능한 구성 요소를 빌드하여 불변의 인프라를 만드는 것을 의미할 수 있습니다. 따라서 버전 제어 및 변경 내역을 제공합니다. 이를 통해 모든 제품 기여자들이 작업 중인 제품의 최종 결과에 더 많은 관심을 갖도록 할 수도 있습니다. 그렇다면 이는 어떻게 작동할까요? 사용자는 어떻게 상호작용할까요? 사람들이 품질에 관심을 갖도록 하는 것은 비즈니스 가치와 사용성 모두에 관심을 갖는 것을 의미합니다. 이것이 바로 DevOps 도입의 진정한 결과입니다.

이러한 광범위한 구매는 서로 다른 기술과 도메인 전문성을 가진 사람들의 대대적인 협조가 필요하기 때문에 소프트웨어 팀이 달성하기가 특히 어렵습니다. 이를 위해서는 교차 기능 팀 구조와 사려 깊은 커뮤니케이션이 모두 필요합니다. 예를 들어 엔지니어가 데이터베이스 문제에 대해 비즈니스 측면의 누군가와 대화해야 하는 경우, 이들은 작업 중인 데이터를 보여줄 뿐만 아니라 필요한 배경 정보를 제공하고 그 사람이 관심을 가져야 하는 사항과 그 이유에 집중해야 합니다.

그렇다면 여러분은 그러한 새 도구를 도입해야 할까요? 대답은 ‘아마도’입니다. 도구는 때때로 빠르게 해결책을 제시하는 것처럼 보일 수 있지만, 어떤 상황에서나 적용되는 솔루션은 아닙니다. 새로운 DevOps 도구를 도입하기 전에 이러한 점을 염두에 두면 성공 가능성이 높아질 것입니다. 최고의 CI/CD 도구는 자신의 팀에 효과적인 도구입니다.

관련 게시물:

DevOps로 전환: 어떤 도구가 필요할까요? 작성자: June Jung
팀에 새 도구를 도입하는 방법(그리고 그 과정에서 반발을 사지 않는 방법) 작성자: Emma Webb
업데이트: CircleCI가 매달 3,000만 개가 넘는 빌드를 처리하는 방법 작성자: Rob Zuber

호스팅된 지속적 통합과 온프레미스 지속적 통합

클라우드 관리 옵션(SaaS)에서 지속적인 통합을 호스팅하거나 사설 인프라의 방화벽 뒤에서 CircleCI를 실행할 수 있습니다.

지속적 통합의 이점

지속적 통합의 기본 원칙은 아주 간단합니다. 코드를 매일 최소 한 차례 이상 커밋하고 통합하는 것입니다. 소프트웨어 개발 프로세스에서의 이러한 사소한 변화는 엄청난 결과로 이어질 수 있습니다.

이 개발 전략을 사용하면 다음과 같은 이점을 얻을 수 있습니다.

• 팀 생산성 및 효율성 개선
• 시장 출시 시간 단축
• 제품/시장 적합도 파악
• 더 우수한 품질로 더 안정적인 제품 출시
• 고객 만족도 향상
• 개발자 만족도를 유지하고 코드 배포

이렇게 단순한 워크플로 변경으로도 이러한 이점을 얻을 수 있는 비결은 무엇일까요?

더 자주 커밋하면 병합 충돌을 조기에 식별 및 해결하고 방지할 수도 있습니다. 천 줄의 코드를 쓰고 오류를 찾는 대신 백 줄의 코드만 작성하면 됩니다. 코드에서 버그를 찾는 데 걸리는 시간이 몇 시간에서 몇 분으로 단축됩니다. 이를 통해 팀 생산성이 향상되고 개발자가 작업 코드를 보다 빠르게 배포할 수 있습니다.

새로운 기능을 빠르게 배포한다는 것은 시장 출시 속도가 높아진다는 것을 의미합니다. 이를 통해 팀은 다음과 같은 두 가지 방법으로 경쟁 우위를 점할 수 있습니다.

1. 고객은 새로운 기능에 더 빨리 액세스하여 고객 만족도를 높일 수 있습니다.

2. 회사는 새로운 기능을 통해 투자 수익을 더 빠르게 얻을 수 있습니다. 코드를 출시하기 위해 다음 마일스톤까지 기다리는 대신 새로운 기능이 시장 출시 준비를 마치는 대로 가치를 제공할 수 있습니다.

오픈 소스 프로젝트를 위한 CI/CD

CircleCI는 매월 무료 플랜에 가입한 모든 조직에 오픈 소스 Linux 빌드에 사용할 수 있는 400,000개의 크레딧을 제공합니다. 이것을 이용하려면 리포지토리를 공개 상태로 유지하세요. MacOS를 기반으로 빌드하는 경우 CircleCI는 매월 무료 플랜에 가입한 조직에 오픈 소스 MacOS 빌드에 사용할 수 있는 25,000개의 무료 크레딧을 제공합니다. 이것을 이용하려면 billing@circleci.com으로 문의하세요.

지속적 통합 모범 사례

지속적 통합을 실행하는 개발자는 조기에 그리고 자주 커밋합니다. 이를 통해 프로덕션에 코드를 배포하기 전에 충돌을 감지할 수 있습니다. 또한 커밋 규모가 작으면 문제 발생 시 코드 문제를 보다 쉽게 해결할 수 있습니다. 소프트웨어를 매일 한 차례 이상 커밋하는 것도 지속적 통합을 위해 필요하지만 이것으로는 충분하지 않습니다.

지속적 통합을 성공적으로 사용하려는 팀은 다음을 수행해야 합니다.

• 테스트를 개발 프로세스의 필수적인 부분으로 만듭니다. 테스트는 코드가 생성될 때 작성되어야 합니다.
• 테스트 환경이 프로덕션을 반영하는지 확인합니다.
• 페어 프로그래밍과 같은 코딩 모범 사례를 활용합니다.
• 배포 워크플로를 자동화합니다.

엄격한 테스트 문화를 조성하는 것은 지속적 통합의 성공을 위해 회사에 필요한 가장 중요한 요소입니다. 새로운 코드를 주요 리포지토리에 확실하게 통합하기 위해서는 코드가 온전하다라는 확신이 필요합니다. 엔지니어는 각 기능이 개발되는 동안 테스트를 작성해야 합니다. CircleCI에서는 커밋된 모든 새로운 코드에 대해 테스트를 실행하며, 시스템에서 개발자에게 ‘녹색’ 빌드에 성공했는지 또는 빌드가 ‘빨간색’이라서 문제를 수정해야 하는지를 알려줍니다. 물론 테스트를 수행하지 않는다면 녹색 빌드는 의미가 없습니다. 팀이 자동 테스트를 사용하는 것이 가장 좋지만, 필수 사항은 아닙니다. Rainforest QA와 같은 QA 서비스를 지속적 통합 프로세스에 통합할 수 있습니다.

엄격한 테스트 문화를 지원하려면 테스트 환경이 프로덕션 환경을 반영하는 것이 중요합니다. 그렇지 않으면 테스트 중인 환경이 프로덕션 환경에서 작동한다는 보장이 없습니다. 즉, 테스트 환경에서 동일한 버전의 데이터베이스, 웹 서버 구성, 아티팩트 등을 사용해야 합니다.

소프트웨어 개발을 위한 또 다른 모범 사례는 코딩 중 페어링하는 것입니다. 보다 복잡한 기능의 경우, 한 줄의 코드가 작성되기 전에 페어가 아키텍처 접근 방식에 대해 논의합니다. 코드가 프로덕션으로 병합되기 전에 다른 개발자는 항상 코드를 검토합니다. 이렇게 하면 코딩 모범 사례가 사용되고, 코드가 기존 코드 또는 다른 개발자가 작업 중인 코드와 충돌하지 않도록 보장하며, 새로운 기능을 확장할 수 있습니다.

마지막으로 전체 소프트웨어 개발 파이프라인을 빠르고 효율적으로 만들려면 배포 워크플로도 자동화되어야 합니다. 배포 워크플로를 자동화하면 팀이 완성된 코드를 보다 빠르게 프로덕션에 투입할 수 있습니다. 고객에게 전달하지 못한다면 소프트웨어를 빨리 개발하는 것도 소용없기 때문입니다.

지속적 통합을 추적하기 위한 주요 지표

지속적 통합은 모든 소프트웨어 개발 팀에게 중요한 목표입니다. 그런데 그 목표를 달성했는지 어떻게 알 수 있을까요? 여기서 핵심 성과 지표가 도움이 됩니다. 소프트웨어 개발 주기를 개선하려면 소프트웨어 개발 주기를 구성하는 프로세스를 측정해야 합니다. 이를 통해 프로세스의 변화가 차이를 만들어내는지 확인할 수 있습니다.

다음은 소프트웨어 개발을 측정하기 위한 4가지 핵심 성과 지표(KPI)입니다.

• 리드 타임: 리드 타임은 워크플로가 처음 시작할 때부터 완료될 때까지 걸리는 시간입니다. 이는 여러분이 얼마나 빨리 신호를 받을 수 있는지를 나타내는 척도입니다. 리드 타임을 단축하려면 최대한 자동화된 소프트웨어 개발 파이프라인이 필요합니다. 그렇기 때문에 팀은 지속적 통합을 사용해 빌드 및 테스트를 자동화해야 합니다. CI를 통해 파이프라인을 자동화하면 배포 일정을 몇 개월에서 몇 주 또는 몇 시간, 심지어 몇 분으로까지 단축할 수 있습니다.
• 배포 빈도: 팀이 워크플로를 시작하는 빈도는 개발 파이프라인을 통해 이동하는 개별 작업 단위 수를 나타냅니다. 완전히 자동화된 소프트웨어 개발 파이프라인을 사용하면 코드베이스에 대한 복잡한 업데이트도 자동으로 배포할 수 있습니다. 핫픽스를 즉시 사용할 수 있습니다. 핫픽스는 다른 업데이트와 동일한 엄격한 테스트를 거칩니다.
• 평균 복구 시간(MTTR): 평균 복구 시간은 실행 가능한 정보를 얼마나 빠르게 얻느냐에 달려 있습니다. 실패 상태를 빠르게 반환하면 최단 시간 내에 빨간색에서 녹색으로 전환할 수 있습니다. CI/CD 방식을 도입하면 빠른 피드백 루프가 가능하게 하므로 개발자에게 빠른 신호를 보낼 수 있는 가장 좋은 방법입니다. 안정적인 CI/CD 방식에는 테스트의 로그 및 범위 보고서와 같은 실시간 아티팩트가 포함되며, 이를 통해 개발자는 프로덕션 환경과 동일한 환경에서 문제를 해결할 수 있습니다.
• 변경 실패율: 성과가 가장 높은 팀들은 기본 브랜치로 잘못된 코드를 푸시하는 경우가 드뭅니다. 이러한 팀들이 절대로 잘못된 코드를 작성하지 않는다는 것이 아닙니다. 테스트 및 보안 검사는 별도의 브랜치에서 수행되며 모든 항목이 통과했을 때만 병합이 허용됩니다. 팀은 코드가 기본 브랜치에 병합되기 전에 잘 작동한다는 것을 알아야 합니다.

정기적으로 보고하는 것이 도움이 됩니다. 자동화된 일일 보고서를 사용하면 오류가 발생했을 때 팀이 오류를 빠르게 파악할 수 있습니다. 또한 주간 보고서를 분석하면 팀이 CI 프로세스를 더욱 심층적으로 살펴보고 개선 영역을 찾을 수 있습니다.

2022 소프트웨어 전달 상태 보고서 다운로드

CI/CD 파이프라인에 테스트 추가하기

여러 유형의 테스트에 대해 이야기해보겠습니다.

유닛/구성 요소 테스트

여기에는 가능한 최소 구성 요소, 유닛 또는 기능이 포함됩니다. 많은 종속성이나 모형 제작이 필요하지 하지 않기 때문에 실행이 빠르고 비용이 적게 듭니다. 이러한 테스트는 방해가 되지 않도록 초반에 완료되어야 합니다.

통합 테스트

이 테스트는 이전 단계의 각 유닛이 다른 구성 요소, 유닛, 기능과 얼마나 잘 작동하는지 확인합니다. 보다 넓은 의미에서 서비스(예: API)가 서로 어떻게 통합되는지 테스트할 수 있습니다.

UI 레이어 테스트

기본 사용자 흐름을 테스트하는 자동화된 브라우저 기반 테스트입니다. 설정 비용이 많이 들고 실행 속도가 느리기 때문에 파이프라인 후반부에 진행해야 합니다.

이번에는 이러한 테스트가 소프트웨어 개발 파이프라인에 얼마나 적합한지 이야기해보겠습니다. 각 테스트에는 저마다 적합한 역할과 위치가 있습니다.