지속적 통합이란 무엇입니까?
지속적 통합은 동일한 코드에서 작업하는 여러 개발자가 수행한 코드 변경 사항을 단일 소프트웨어 프로젝트에 지속적으로 통합하는 관행입니다. 이 통합은 일반적으로 코드에 대한 모든 변경 사항이 올바르게 기록되도록 온종일 진행되는 프로세스로 자동 업데이트됩니다. 이 전략은 협업, 규모를 고려한 설계 및 지속 가능성 구축이라는 개념을 기반으로 구축된 에자일 소프트웨어 개발 시스템의 필수 부분입니다.
1994년 "지속적 통합"이라는 용어는 UML(통합 모델링 언어) 개발 뿐만 아니라 소프트웨어 아키텍처 및 공동 개발자 환경에서의 혁신적인 작업으로 하여 가장 잘 알려진 미국 소프트웨어 엔지니어 Grady Booch에 의해 처음 도입되었습니다. 지속적 통합은 1997년부터 일반적으로 사용되었으며 현재 소프트웨어 개발을 위한 모범 사례로 널리 받아들여지고 있습니다. 지속적 통합 프로세스가 20년 전과 오늘날에는 약간 달라 보일 수 있지만 그 배경 이론은 여전히 같은 것입니다.
지속적 통합이 얼마나 중요한가를 이해하는 한 가지 방법은 코딩 소프트웨어를 집을 짓는 것으로 생각하는 것입니다. 집을 짓는 경우 건물이나 소프트웨어의 특정 부분을 오프사이트에 구축하는 다양한 빌더 또는 개발자가 있습니다. 그들은 서로 다른 시간에 작업을 시작하고 중지할 수 있으며 아키텍처의 한 부분에서 오류나 편차가 있으면 집이나 프로그램의 나머지 부분을 불안정하게 만들거나 완전히 사용할 수 없게 될 수 있습니다.
이러한 비유에서, 지속적 통합을 추가할 때, 빌더는 모든 부분이 제대로 함께 작동하는지 확인하기 위해 하루에 여러 번 현장을 방문하여 그들이 완성한 작업물을 설치해야 합니다. 창틀이든 지붕이든, 집의 기존 부분에 맞는지 확인하기 위해 올바르게 수행되고 테스트되어야 합니다. 같은 논리로 지붕이 아직 설치되어 있지 않다면 주방 캐비닛을 설치하는 것은 의미가 없습니다. 지속적 통합은 개발자가 같은 페이지에 있지 않을 경우 발생할 수 있는 잠재적인 오류나 문제를 최소화하는 데 도움이 됩니다.
지속적 통합을 사용하는 이유는 무엇입니까?
소프트웨어 개발은 종종 여러 대규모 팀에서 취급하므로 일반적으로 다른 시간대와 지리적 영역에 걸쳐 분산되게 됩니다. 이 때문에 여러 사람이 동시에 소프트웨어의 같은 부분을 작업할 때 다른 사람이 무엇을 하는지 알 수 없게 되면서 개발의 청크가 한꺼번에 발생할 것입니다.
지속적 통합은 다음을 보장하는 데 도움이 됩니다.
시간 절약: 이는 작업의 중복을 제거하고 가능한 모든 테스트 및 병합 프로세스를 자동화할 뿐만 아니라 테스트 및 수정 작업을 통해 처리 시간을 단축하고 버그 및 오류를 찾는 데 낭비되는 시간을 줄일 수 있기 때문에 가장 큰 이점일 것입니다. 번다운 차트를 보고 있는 프로젝트 관리자는 완료되어 업로드되는 작업을 쉽게 볼 수 있습니다. 시간 절약에는 상당한 비용을 절감하는 추가 보너스가 동반됩니다.
훨씬 더 강력한 완제품: 많은 부분이 대부분 자동화된 소프트웨어의 정기적이고 철저한 테스트를 통해 다음 개발 단계에서 버그 수정이 적어지게 됩니다. 이는 또한 최종 제품에서 버그와 오류를 줄여 최종 사용자의 만족도를 개선한다는 것을 미합니다.
소통 증가: 지속적인 코드 공유는 직장 내 소통의 속도와 효율성을 높입니다.
더 빠른 소프트웨어 출시: 고객이 사용하는 기존 소프트웨어에서 문제가 발견되거나 새로운 바이러스가 출현하면 이를 해결하기 위한 개발 주기가 훨씬 빨라집니다. 아주 짧은 시간 안에 작은 변경 사항을 수정하고 테스트하고 다시 출시할 수 있습니다.
전반적으로 코드의 신뢰성이 향상되고 오류와 버그가 줄어들며 많은 시간과 비용을 절약하고 최종 사용자에게 보다 만족스러운 결과를 가져다 줍니다. 이것은 모든 기업이 실천해야 할 위험 완화의 한 형태입니다.
지속적 통합이 지속적 배포에 어떻게 적합합니까?
지속적인 배포 실천을 통해 소프트웨어는 버그가 없고 언제든지 배포할 준비가 되어 있으며 "지속적으로" 배포되어 신뢰성을 유지합니다. 예를 들어 휴대폰에서 소프트웨어 업데이트를 받는 경우가 많습니다. 이 새로운 배포를 통해 애플리케이션이 모두 최신 상태로 안전하게 유지됩니다. 이러한 방식으로 소프트웨어를 언제든지 배포할 수 있으며 종종 중요한 업데이트를 통합합니다. 소프트웨어가 지속적으로 업데이트되고 테스트되고 사용에 적합한 것으로 간주되는 것으로 하여 지속적 통합은 지속적인 배포의 중요한 부분입니다. 지속적 배포는 언제든지 소프트웨어를 배포할 수 있거나 고객이 요구할 수 있다는 이론이므로 소프트웨어는 반드시 항상 사용할 준비가 되어 있어야 합니다.
지속적 통합 및 지속적 배포의 8단계
간단히 말해서, CI/CD(지속적 통합/지속적 전달) 주기는 빠르고 효과적이며 안정적인 소프트웨어 개발을 보장하는 8단계의 지속적으로 반복되는 애자일 프로세스입니다. 1~4단계는 지속적 통합의 범주에 속하는 반면 5~8단계는 지속적 전달 프로세스의 일부로 간주됩니다.
- 계획: 애플리케이션 변경은 제품 팀에서 계획합니다. 여기에는 애플리케이션의 버그 수정, 성능 향상 또는 새 기능 추가가 포함될 수 있습니다.
- 코드: 개발자는 로컬 컴퓨터에서 소프트웨어를 코딩합니다. 각 개발자는 시스템에서 개발하거나 버그를 해결해야 할 고유한 부분이 있습니다.
- 빌드: 개발자가 두 번째 단계를 완료하면 새 코드가 코드 저장소에 제출되고 애플리케이션이 컴파일됩니다.
- 테스트: 테스터는 코드의 기능과 유용성을 확인합니다. 코드가 의도한 대로 작동하는지, 또한 기존 코드의 나머지 부분과 작동하는지 여부도 테스트합니다. 새 코드가 이미 패키지의 일부로 된 다른 부분을 방해하지 않는지 확인하기 위해서는 자동화된 테스트를 사용해야 합니다. 코드가 허용 가능한 것으로 간주되면 병합됩니다. 아직 해결해야 할 오류가 있으면 개발자에게 다시 돌려보냅니다.
- 릴리스: 코드가 완료되면 교정된 코드가 소프트웨어와 병합되고 자동 릴리스로 설정되여 승인 대기 상태에 들어갑니다.
- 배포: 코드가 프로덕션에 자동으로 배포됩니다.
- 작동: 이 시점에서 이제 새 코드를 프로덕션 환경 내에서 작동할 수 있습니다.
- 모니터링: 애플리케이션 성능을 지속적으로 모니터링하여 버그를 찾고 성능을 개선해야 할 영역을 식별합니다. 이것은 수집하고 분석한 데이터를 1단계를 담당하는 제품 팀에 전달하여 애플리케이션의 변경 및 개선 사항을 지속적으로 계획할 수 있도록 해야 하는 지속적인 피드백 주기입니다.
지속적 통합의 이점
많은 애자일 팀이 지속적 통합을 사용하는 이유는 이 지속적 통합이 많은 소프트웨어 개발 문제를 해결하는 데 믿을 수 없을 정도로 잘 작동하기 때문입니다. 두 명의 개발자가 동시에 동일한 코드에서 작업하지 않도록 방지하여 불필요한 이중화를 방지합니다.
또한 지속적 통합을 통해 팀은 항상 최신 소프트웨어 업데이트에 기반하여 작업할 수 있으므로 가장 최근의 변경 사항을 기반으로 구축할 수 있습니다. 모든 사람이 자신의 코드를 업로드하고 다른 작업 및 작업 섹션에 대해 버전을 확인하려고 하므로 릴리스 날짜에 최종 혼란이 발생하지 않습니다.
개발 과정에서 한 줄 변경 또는 마침표나 잘못된 브래킷과 같은 작은 항목이라도 소프트웨어의 다른 부분을 부주의하게 손상시킬 수 있습니다. 잦은 업데이트를 통해 상기 문제의 원인을 쉽게 식별하고 다른 영역으로 이동하기 전에 문제를 해결할 수 있습니다. 또한 개발자가 작업을 자주 저장하도록 하고 완성된 코드 조각이 로컬 전원이나 인터넷 중단을 피해 안전한 공유 리포지토리(종종 클라우드)에 저장되도록 합니다.
지속적 통합은 통합 충돌 및 오류를 방지하는 데 도움이 됩니다. 다른 개발자가 작업을 업데이트하면 아직 제출되지 않은 다른 작업에 영향을 줍니다. 정기적인 업데이트는 이러한 잠재적 충돌을 최소화합니다. 실제로 코드가 제출된 직후 변경, 충돌 또는 문제를 신속하게 식별할 수 있습니다. 이는 개발자가 아직 생생하게 기억하는 상태에서 즉시 업무에 복귀하여 수정할 수 있다는 것을 의미합니다.
지속적인 코드 체크인은 또한 개발자가 덜 복잡한 모듈식 코드 작성에 도움이 되며, 지속적 통합의 자동화된 특성을 통해 시간 소모적인 수동 테스트를 줄일 수 있습니다. 마지막으로 지속적 배포에 현재 완성된 빌드를 지속적으로 사용할 수 있다는 이점이 있습니다.
지속적 통합의 과제
그러나 지속적 통합의 구현에는 여러 가지 문제가 존재합니다. 많은 기술과 마찬가지로 자원 할당, 교육 부족, 레거시 코드 자동화 프로세스 등 여러 가지 문제로 인해 지속적으로 발전하고 있는 분야입니다.
문제: 새로운 관행으로 지속적인 통합의 출시입니다. 회사가 이미 일정 기간 동안 개발을 수행하고 지속적 통합을 사용한 적이 없는 경우, 실행을 한 번에 모두 구현하려고 하면 순식간에 압도되거나 불가능해 보일 수 있습니다. 지속적 통합을 구현하려면 수동 시스템에서 고도로 자동화된 개발 환경으로 점진적으로 이동하는 여정이 필요합니다. 올바른 코드 저장소를 찾고, 개발자가 업데이트하도록 교육하고, 테스터가 개발자와 함께 작업하도록 하는 데는 모두 시간, 인내, 팀 간의 많은 협업이 필요합니다. 또한 이 과정에서 UX 또는 기능 테스트를 먼저 수행해야 하는지, 테스트를 자동화해야 하는 지, 어떤 소프트웨어가 가장 좋은 지 등과 같은 많은 결정을 내려야 합니다. 이것은 기업의 일상적인 운영과 책임 문화의 큰 변화입니다.
솔루션: 시차 출시는 이러한 주요 변경 사항에서 불안을 어느 정도 해소할 수 있으며 팀이 변경 사항에 익숙해지는 데 도움이 됩니다. 이것은 또한 사람들이 팀으로서 작은 작업에서 보다 자연스러운 방식으로 프로세스를 배울 수 있음을 의미합니다. 이러한 문화 변화는 해결하기 어렵지만 지속적 통합은 개발자 팀 간의 협업 정신을 고취시키고 궁극적으로 도움이 될 것입니다.
문제: 종종 지속 통합과 지속 배포에 대한 잘못된 이해입니다. 일부 기업은 지속적 통합과 지속적 배포를 혼동하거나 상호 연관 시킵니다. 이 두 자는 서로 다른 두 개의 개별 프로세스이며 지속적 통합을 자동으로 배포할 필요가 없습니다. 소프트웨어를 지속적으로 업데이트하는 것은 모든 회사에 적합하지 않을 수 있으며 문제가 될 수도 있습니다. 지속적 통합을 통해 기본 코드를 항상 배포할 준비가 되어 있어야 하지만 반드시 배포해야 하는 것은 아닙니다.
솔루션: 이에 대한 이 해결책은 기본적으로 교육입니다. 경영진이 각 프로세스를 더 잘 이해하게 되면, 어느 것이 이점과 비즈니스에 적합한지 명확하게 알 수 있습니다.
문제: 반복적인 진행 중인 프로세스입니다. 개발 체인 전체에 많은 시간이 소요되고 반복적인 프로세스가 존재하게 됩니다. 이러한 작업은 고도로 숙련된 개발자에게 좌절감을 줄 뿐만 아니라 오류가 발생하기 쉽습니다.
솔루션: 가능한 모든 프로세스를 자동화해야 합니다. 테스트, 구축 및 배포와 같은 작업 등수동으로 수행하는 작업은 대부분 거의 완전히 자동화할 수 있습니다. 자동화는 오류 없는 프로세스를 보장하고 개발자가 단순한 작업 주기에 얽매이지 않고 계속해서 새로운 소프트웨어를 개발할 수 있도록 합니다.
문제: 레거시 코드입니다. '레거시 코드'가 포함된 기존 시스템이 있는 경우 해당 코드에 대한 테스트를 자동화하는 데 일반적으로 길고 복잡한 프로세스가 필요합니다.
솔루션: 레거시 코드 변환의 장단점을 비교하는 것이 중요합니다. 작업을 완료하고 병합한 다음 수동으로 테스트해야 합니다. 이 경우 지속적 통합이 이 프로젝트의 정답인지에 대해 논의하는 것은 가치가 있습니다.
지속적 통합 시작 및 확장
종종 비즈니스 또는 소프트웨어 개발 팀은 소규모 범위에서 시작할 수 있습니다. 이 소규모 팀은 격리된 코드 부분에서 작업한 다음 '병합의 날'을 정하여 완료된 모든 작업을 동시에 병합할 수 있습니다. 이는 역할과 작업이 매우 잘 정의된 소규모 팀에 가장 적합합니다.
그러나 팀이 커질수록 병합의 날은 빠르게 스트레스와 시간 소모적인 작업이 되어 수많은 충돌, 버그 및 문제가 발생할 수 있습니다. 각각의 개발자들이 그들의 작업 결과를 추가하는 것은 문제를 복잡하게 만들기 때문에 갈등과 오류가 어디서 발생하는지 파악하기가 어렵습니다.
지속적 통합의 기둥
지속적 통합은 기타 여러 소프트웨어 모범 사례를 기반으로 구축됩니다. 여기에는 자동화된 테스트, 빌드 자동화, 버전 제어 및 자동화된 배포와 같은 기술이 포함됩니다. 이들 각각에는 고유한 철학과 도구 생태계가 있으며, 이에 대해서는 아래에서 살펴보겠습니다.
버전 컨트롤 관리
버전 컨트롤은 지속적인 통합의 핵심 요소입니다. 버전 소스 관리를 통해 동일한 코드 기반에서 동시에 작업하는 개발자들은 서로 소통하여 충돌을 해결합니다.
자동화된 테스트
모든 소프트웨어 프로젝트는 철저하고 반복적인 테스트가 필요합니다. 이는 시간이 많이 걸리고 반복적일 수 있으므로 테스트 프로세스의 일부를 자동화하는 도구가 개발되었습니다. 이러한 테스트 도구는 시스템의 특정 부분에서 테스트 케이스를 자동으로 실행합니다. 개발자가 리포지토리로 코드를 푸시하면 자동화된 테스트가 시작됩니다.
빌드 자동화
빌드는 종종 현재 릴리스 모듈의 스냅샷이라고 합니다. 이러한 빌드는 결과적으로는 다양한 잠재적인 채널을 통해 최종 사용자에게 배포됩니다. 지속적 통합 도구는 릴리스 빌드 프로세스를 간소화하는 데 도움이 됩니다. 빌드 자동화는 특정 이벤트에 의해 트리거되도록 릴리스를 설정할 수도 있습니다. 예를 들어, 새로운 코드 조각이 코드베이스의 프로덕션 분기에 병합되면 사용자가 액세스하고 다운로드할 수 있는 원격 서버에 빌드를 업로드하는 자동화가 트리거됩니다.
자동화된 배포
각 배포 프로세스는 구축 대상에 따라 다릅니다. 예를 들어 자동화된 소프트웨어는 웹 페이지를 웹 서버에 배포합니다. 이전 단계에서 생성된 빌드는 웹 프로젝트용 웹 서버에 자동으로 복사되고, 앱 업데이트를 위해 스토어에 업로드되며, 배포해야 하는 다른 모든 채널에 업로드됩니다.
지속적 통합은 성공적인 소프트웨어 개발의 열쇠입니다
지속적 통합은 철저하고 정기적인 테스트와 빠르고 정확한 버그 수정을 통해 협업을 장려하는 환경과 더욱 강력하고 안정적인 소프트웨어를 만들어 애자일 개발 팀과 기업이 목표를 달성하는 데 도움이 되기 때문에 중요합니다.