지속적인 통합

Continuous integration
시리즈의 일부
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원 분야
프랙티스
도구들
지식의 표준과 본문
용어집
개요

소프트웨어 엔지니어링에서 CI(Continuous Integration)는 모든 개발자의 작업 복사본을 하루에도 [1]여러 번 공유 메인라인에 병합하는 작업입니다.Grady Boch는 1991년 [2]방법에서 CI라는 용어를 처음 제안했지만 하루에 여러 번 통합을 지지하지는 않았습니다.Extreme Programming(XP; 익스트림 프로그래밍)은 CI의 개념을 채택하여 하루에 [3]한 번 이상(아마도 하루에 수십 번) 통합을 지지했습니다.

근거

변경 작업을 시작할 때 개발자는 작업할 현재 코드 베이스의 복사본을 가져옵니다.다른 개발자가 변경된 코드를 소스 코드 저장소에 제출하면 이 복사본은 저장소 코드를 반영하지 않게 됩니다.기존 코드 베이스가 변경될 수 있을 뿐만 아니라 새로운 코드와 새로운 라이브러리 및 의존관계를 생성하는 기타 리소스 및 잠재적인 충돌을 추가할 수 있습니다.

메인라인에 머지하지 않고 브랜치로 개발을 계속하는 시간이 길어질수록 개발자 브랜치가 최종적으로 머지백될 때 여러 통합의[4] 경합과 장애가 발생할 위험이 높아집니다.개발자는 저장소에 코드를 제출할 때 먼저 복사본을 가져온 이후의 저장소 변경 사항을 반영하도록 코드를 업데이트해야 합니다.저장소에 포함된 변경 내용이 많을수록 개발자가 직접 변경 내용을 제출하기 전에 수행해야 하는 작업이 많아집니다.

결국 저장소는 개발자의 기준과 크게 달라져 통합에 소요되는 시간이 원래 [6]변경에 소요된 시간을 초과하는 '통합 지옥'[5]이라고도 불리는 곳에 들어갈 수 있습니다.

워크플로우

로컬로 테스트 실행

CI는 테스트 주도의 개발 관행을 통해 작성된 자동화된 유닛 테스트와 조합하여 사용하도록 의도되어 있습니다.이는 메인라인에 커밋하기 전에 개발자의 로컬 환경에서 모든 유닛 테스트를 실행하고 통과함으로써 이루어집니다.이를 통해 한 개발자가 진행 중인 작업이 다른 개발자의 복사본을 손상시키는 것을 방지할 수 있습니다.필요한 경우 기능 토글을 사용하여 커밋하기 전에 부분적으로 완전한 기능을 비활성화할 수 있습니다.

CI에서 코드 컴파일

빌드 서버는 정기적으로 또는 매번 커밋된 후에도 코드를 컴파일하여 개발자에게 결과를 보고합니다.빌드 서버의 사용은 XP(익스트림 프로그래밍) 커뮤니티 이외에서 도입되어 많은 조직이 XP를 모두 채택하지 않고 CI를 채택하고 있습니다.

CI에서 테스트 실행

CI를 사용하는 조직은 자동 유닛 테스트와 더불어 일반적으로 빌드 서버를 사용하여 품질관리 전반을 적용하는 연속적인 프로세스를 구현합니다.이것은 작은 노력이 자주 적용됩니다.이러한 프로세스는 유닛 및 통합 테스트 실행 외에 추가 정적 분석, 성능 측정 및 프로파일링, 소스 코드에서 문서 추출 및 포맷, 수동 QA 프로세스도 지원합니다.널리 사용되는 오픈 소스용 Travis CI 서비스에서는 CI 작업의 58.64%만이 [7]테스트를 실행합니다.

이러한 품질관리의 지속적인 적용은 모든 개발을 완료한 후 품질관리를 적용하던 종래의 관행을 대체함으로써 소프트웨어의 품질을 향상시키고 이를 전달하는 데 걸리는 시간을 단축하는 것을 목적으로 한다.이는 QA 프로세스에만 적용되는 통합을 보다 쉽게 하기 위해 더 자주 통합한다는 당초 생각과 매우 유사합니다.

CI에서 아티팩트 배포

CI는 흔히 CI/CD 파이프라인이라고 불리는 지속적인 제공 또는 지속적인 구축과 얽혀 있습니다.「지속적인 전달」에 의해서, 메인 라인상에서 체크인 된 소프트웨어가 항상 유저에게 전개 가능한 상태가 되어 있는 것을 확인할 수 있습니다.「지속적인 전개」에 의해서, 도입 프로세스가 완전하게 자동화됩니다.

역사

연속 통합에 관한 최초의 연구는 G. E. Kaiser, D. E. Perry 및 W. M. Shell에 [8]의해 개발된 Infuse 환경이었다.

1994년 Grady Boch는 오브젝트 지향 분석 및 설계 with Applications (제2판)[9]에서 "내부 릴리스는 마이크로 프로세스를 사용하여 시스템을 지속적으로 통합할 수 있으며 마이크로 프로세스를 강제로 종료하기 위해 존재한다"는 문구를 사용했습니다.

1997년 Kent Beck와 Ron Jeffries는 지속적인 [1][self-published source]통합을 포함한 크라이슬러 종합 보상 시스템 프로젝트를 진행하면서 Extreme Programming(XP)을 발명했습니다.벡은 1998년에 지속적인 통합에 대해 발표하면서 [10]기술 지원보다 대면 커뮤니케이션이 중요하다는 점을 강조했습니다.1999년, 벡은 익스트림 [11]프로그래밍에 관한 그의 첫 번째 전체 책에서 더 자세히 설명했습니다.최초의 오픈 소스 CI [12][self-published source]툴 중 하나인 CruiseControl은 2001년에 출시되었습니다.

2010년, Timothy Fitz는 IMVU의 엔지니어링 팀이 최초의 실용적인 CI 시스템을 구축하고 어떻게 사용하고 있었는지에 대한 자세한 기사를 실었습니다.그의 글은 처음에는 회의적이었지만, 곧 인기를 끌었고 IMVU를 기반으로 한 린 소프트웨어 개발 방법론의 일부로[13] 널리 채택되었습니다.

일반적인 프랙티스

이 섹션에서는 다양한 저자가 제안한 지속적인 통합 방법 및 이 방법을 자동화하는 방법에 대한 베스트 프랙티스를 나열합니다.빌드 자동화는 베스트 프랙티스 그 [14][15]자체입니다.

새로운 코드 또는 변경된 코드를 기존 코드 저장소와 자주 통합하는 방식인 지속적인 통합은 커밋과 빌드 사이에 방해되는 창이 남아 있지 않을 정도로 자주 발생해야 하며 개발자가 이를 알아차리고 즉시 [1]수정하지 않는 한 오류가 발생하지 않아야 합니다.일반적으로 이러한 빌드는 정기적으로 예약된 빌드가 아니라 저장소에 대한 모든 커밋에 의해 트리거됩니다.멀티 디벨로퍼 환경에서 고속 커밋을 실시하면, 통상, 각 커밋 후에 짧은 시간을 트리거 해, 이 타이머가 기한이 지났을 때, 또는 마지막 빌드로부터 꽤 긴 인터벌 후에 빌드를 개시합니다.새로운 커밋마다 짧은 시간 트리거에 사용되는 타이머가 리셋되므로 이는 많은 버튼 디버깅알고리즘에서 [16]사용되는 것과 동일한 기술입니다.이렇게 하면 일련의 고속 커밋 간에 불필요한 빌드를 방지하기 위해 커밋이벤트가 "디버깅"됩니다.많은 자동화 도구에서 이 스케줄을 자동으로 제공합니다.

또 다른 요인은 원자적 커밋을 지원하는 버전 제어 시스템의 필요성입니다. 즉, 개발자의 모든 변경은 단일 커밋 작업으로 간주될 수 있습니다.변경된 파일의 절반만 사용하여 빌드하려고 해도 의미가 없습니다.

이러한 목적을 달성하기 위해 지속적인 통합은 다음 원칙에 의존합니다.

코드 저장소 유지 관리

주요 기사:버전 관리

이 프랙티스는 프로젝트의 소스 코드에 대한 수정 제어 시스템의 사용을 지지합니다.프로젝트 구축에 필요한 모든 아티팩트는 저장소에 저장해야 합니다.이 프랙티스와 개정관리 커뮤니티에서는 시스템을 신규 체크아웃에서 구축할 수 있어야 하며 추가 의존관계가 필요하지 않아야 한다는 것이 관례입니다.Extreme Programming의 옹호자인 Martin Fowler는 툴에 의해 브랜칭이 지원되는 경우에는 [17]그 사용을 최소화해야 한다고 언급하고 있습니다.대신 여러 버전의 소프트웨어를 동시에 유지하는 것보다 변경 내용을 통합하는 것이 좋습니다.메인라인(또는 트렁크)은 소프트웨어의 현용 버전을 보관하는 장소여야 합니다.

빌드 자동화

주요 기사:자동화 구축

하나의 명령어로 시스템을 구축할 수 있어야 합니다.제작과 같은 많은 제작 도구들이 오랜 세월 동안 존재해왔다.기타 최신 툴은 지속적인 통합 환경에서 자주 사용됩니다.빌드의 자동화에는 통합의 자동화가 포함되어야 합니다.통합에는 실제 가동 환경으로의 도입이 포함되는 경우가 많습니다.대부분의 경우 빌드 스크립트는 바이너리를 컴파일할 뿐만 아니라 문서, 웹 사이트 페이지, 통계 및 배포 미디어(Debian DEB, Red Hat RPM 또는 Windows MSI 파일 등)도 생성합니다.

빌드 자가 테스트 실시

코드가 작성되면 모든 테스트가 실행되어 개발자가 예상하는 [18]대로 동작하는지 확인해야 합니다.

모든 사람이 매일 기준선을 준수합니다.

모든 커밋은 정기적으로 커밋함으로써 경합하는 변경의 수를 줄일 수 있습니다.일주일치 작업 체크인은 다른 기능과 충돌할 위험이 있어 해결하기가 매우 어려울 수 있습니다.초기에 시스템 영역의 작은 충돌로 인해 팀원들이 [19]변경 사항에 대해 소통하게 됩니다.모든 변경을 적어도 1일 1회(구축된 기능별로 1회) 커밋하는 것은 일반적으로 Continuous Integration 정의의 일부로 간주됩니다.또한 일반적으로 야간에 빌드하는 것이 좋습니다.[citation needed]이것들은 하한이며, 일반적인 주파수는 훨씬 높을 것으로 예상됩니다.

(기준에 대한) 모든 커밋을 구축해야 합니다.

시스템은 현재 동작 중인 버전에 대한 커밋을 작성하여 올바르게 통합되는지 확인해야 합니다.자동 연속 연동을 사용하는 것이 일반적인 방법이지만, 이 방법은 수동으로 수행할 수 있습니다.Automated Continuous Integration은 지속적인 통합 서버 또는 데몬을 사용하여 리비전 제어 시스템의 변경 여부를 모니터링하고 빌드 프로세스를 자동으로 실행합니다.

모든 버그 수정 커밋에는 테스트 케이스가 포함되어 있어야 합니다.

버그를 수정할 때는 버그를 재현하는 테스트 케이스를 푸시하는 것이 좋습니다.이것에 의해, 수정이 되돌아가거나, 버그가 재발하는 것을 회피할 수 있습니다.이것은 회귀라고 불립니다.연구자들은 이 작업을 자동화할 것을 제안했습니다. 버그 수정 커밋에 테스트 케이스가 포함되지 않은 경우 기존 [20]테스트에서 생성할 수 있습니다.

신속한 구축 유지

통합에 문제가 있는 경우 신속하게 식별하기 위해 빌드가 신속하게 완료되어야 합니다.

실가동 환경의 클론에서 테스트

주요 기사:테스트 환경

테스트 환경이 있으면 실제 가동 환경에 도입할 때 테스트된 시스템에서 장애가 발생할 수 있습니다.실가동 환경은 테스트 환경과 크게 다를 수 있기 때문입니다.그러나 프로덕션 환경의 복제본을 구축하는 것은 비용이 많이 듭니다.대신 테스트 환경 또는 개별 사전 운영 환경("스테이징")을 운영 환경의 확장 가능한 버전으로 구축하여 비용을 절감하면서 기술 스택 구성과 뉘앙스를 유지해야 합니다.이러한 테스트 환경에서 서비스 가상화는 일반적으로 팀이 제어할 수 없는 의존관계(API, 서드파티 애플리케이션, 서비스, 메인프레임 등)에 온디맨드 방식으로 액세스하기 위해 사용됩니다.이러한 의존관계는 아직 가상 테스트 랩에서 설정하기에는 너무 복잡합니다.

최신 성과물을 쉽게 입수할 수 있다

이해관계자 및 테스터가 빌드를 쉽게 사용할 수 있도록 하면 요구 사항을 충족하지 못하는 기능을 재구축할 때 필요한 재작업량을 줄일 수 있습니다.또한 조기 테스트를 통해 결함이 배포될 때까지 지속될 가능성이 줄어듭니다.오류를 조기에 발견하면 오류를 해결하는 데 필요한 작업량을 줄일 수 있습니다.

모든 프로그래머는 저장소에서 프로젝트를 업데이트하는 것으로 하루를 시작해야 합니다.그렇게 하면, 그들 모두가 최신 정보를 유지할 수 있을 것이다.

모든 사람이 최신 빌드 결과를 볼 수 있습니다.

빌드가 파손되었는지, 만약 파손되었다면 누가 적절한 변경을 가했는지, 그 변경이 무엇이었는지를 쉽게 알 수 있을 것입니다.

도입 자동화

대부분의 CI 시스템에서는 빌드가 완료된 후 스크립트를 실행할 수 있습니다.대부분의 경우 모든 사용자가 볼 수 있는 라이브 테스트 서버에 애플리케이션을 배포하는 스크립트를 작성할 수 있습니다.이러한 사고방식의 한층 더 진일보한 것은 지속적인 도입입니다.이것에 의해, 소프트웨어를 실가동 환경에 직접 도입할 필요가 있습니다.대부분의 경우, 결함이나 [21][22]퇴행을 방지하기 위한 추가의 자동화가 필요하게 됩니다.

비용과 이점

지속적인 통합은 다음과 같은 이점을 창출하기 위한 것입니다.

  • 연동의 버그는 조기에 검출되어 작은 변경사항으로 인해 추적하기 쉬워집니다.이를 통해 프로젝트 수명 동안 시간과 비용을 모두 절약할 수 있습니다.
  • 모든 사람이 약간 호환되지 않는 버전을 체크인하려고 할 때 출시일에 발생하는 막바지 혼란을 방지합니다.
  • 유닛 테스트가 실패하거나 버그가 발생했을 때 개발자가 디버깅 없이 코드 베이스를 버그가 없는 상태로 되돌릴 필요가 있는 경우 (연동이 빈번히 이루어지기 때문에) 소수의 변경만 손실됩니다.
  • 테스트, 데모 또는 릴리스 목적으로 "현재" 빌드를 지속적으로 사용 가능
  • 잦은 코드 체크인으로 인해 개발자들은 덜 복잡한[citation needed] 모듈식 코드를 작성해야 합니다.

지속적인 자동 테스트를 통해 얻을 수 있는 이점은 다음과 같습니다.

  • 빈번한 자동 테스트의 규율 강화
  • 로컬 변경이 시스템 전체에 미치는 영향에 대한 즉각적인 피드백
  • 자동화된 테스트 및 CI(코드 적용 범위, 코드 복잡성, 기능 완전성 지표 등)에서 생성된 소프트웨어 메트릭은 개발자가 기능, 품질 코드 개발에 집중하고 팀[citation needed] 내 추진력을 개발하는 데 도움이 됩니다.

지속적인 통합의 단점은 다음과 같습니다.

  • 자동화된 테스트 스위트를 구축하려면 새로운 기능을 커버하고 의도적인 코드 수정을 따르기 위한 지속적인 노력을 포함하여 상당한 작업이 필요합니다.
    • 테스트는 지속적인 통합 여부에 관계없이 소프트웨어 개발을 위한 베스트 프랙티스로 간주되며, 자동화는 테스트 주도의 개발과 같은 프로젝트 방법론의 필수적인 부분입니다.
    • 테스트 스위트 없이 지속적인 통합을 수행할 수 있지만, 수작업으로 자주 수행해야 하는 경우 릴리스 가능한 제품을 생산하기 위한 품질 보증 비용이 높을 수 있습니다.
  • 빌드 시스템의 셋업에는 몇 가지 작업이 수반되고 있어,[23] 복잡해지기 때문에 유연하게 수정하기 어렵습니다.
    • 그러나, 전용 소프트웨어 프로젝트와 오픈 소스 프로젝트를 모두 사용할 수 있는 연속적인 통합 소프트웨어 프로젝트에는 여러 가지가 있습니다.
  • 프로젝트의 범위가 작거나 테스트할 수 없는 레거시 코드가 포함되어 있는 경우 지속적인 통합이 반드시 중요한 것은 아닙니다.
  • 부가가치는 테스트의 품질과 코드의 실제 테스트 [24]가능 정도에 따라 달라집니다.
  • 팀이 클수록 새로운 코드가 지속적으로 통합 큐에 추가되기 때문에 품질을 유지하면서 배송을 추적하는 것은 어렵고 빌드 큐잉이 [24]지연될 수 있습니다.
  • 하루에 여러 개의 커밋과 병합을 사용하면 기능의 부분 코드를 쉽게 푸시할 수 있으므로 기능이 [24]완료될 때까지 통합 테스트가 실패합니다.
  • 안전 및 미션 크리티컬 개발 보증(예: DO-178C, ISO 26262)은 지속적인 통합을 사용하여 달성하기 어려운 엄격한 문서화와 진행 중인 검토가 필요하다.이러한 유형의 라이프 사이클에서는 제품의 규제 승인이 필요한 경우 제품 출시 전에 추가 단계를 완료해야 하는 경우가 많습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b c Fowler, Martin (1 May 2006). "Continuous Integration". Retrieved 9 January 2014.
  2. ^ Booch, Grady (1991). Object Oriented Design: With Applications. Benjamin Cummings. p. 209. ISBN 9780805300918. Retrieved 18 August 2014.
  3. ^ Beck, K. (1999). "Embracing change with extreme programming". Computer. 32 (10): 70–77. doi:10.1109/2.796139. ISSN 0018-9162.
  4. ^ Duvall, Paul M. (2007). Continuous Integration. Improving Software Quality and Reducing Risk. Addison-Wesley. ISBN 978-0-321-33638-5.
  5. ^ Cunningham, Ward (5 August 2009). "Integration Hell". WikiWikiWeb. Retrieved 19 September 2009.
  6. ^ "What is Continuous Integration?". Amazon Web Services.
  7. ^ Durieux, Thomas; Abreu, Rui; Monperrus, Martin; Bissyande, Tegawende F.; Cruz, Luis (2019). "An Analysis of 35+ Million Jobs of Travis CI". 2019 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE: 291–295. arXiv:1904.09416. Bibcode:2019arXiv190409416D. doi:10.1109/ICSME.2019.00044. ISBN 978-1-7281-3094-1. S2CID 203593737.
  8. ^ Kaiser, G. E.; Perry, D. E.; Schell, W. M. (1989). Infuse: fusing integration test management with change management. Proceedings of the Thirteenth Annual International Computer Software & Applications Conference. Orlando, Florida. pp. 552–558. doi:10.1109/CMPSAC.1989.65147.
  9. ^ Booch, Grady (December 1998). Object-Oriented Analysis and Design with applications (PDF) (2nd ed.). Retrieved 2 December 2014.
  10. ^ Beck, Kent (28 March 1998). "Extreme Programming: A Humanistic Discipline of Software Development". Fundamental Approaches to Software Engineering: First International Conference. Vol. 1. Lisbon, Portugal: Springer. p. 4. ISBN 9783540643036.
  11. ^ Beck, Kent (1999). Extreme Programming Explained. Addison-Wesley Professional. p. 97. ISBN 978-0-201-61641-5.
  12. ^ "A Brief History of DevOps, Part III: Automated Testing and Continuous Integration". CircleCI. 1 February 2018. Retrieved 19 May 2018.
  13. ^ Sane, Parth (2021), "A Brief Survey of Current Software Engineering Practices in Continuous Integration and Automated Accessibility Testing", 2021 Sixth International Conference on Wireless Communications, Signal Processing and Networking (WiSPNET), pp. 130–134, arXiv:2103.00097, doi:10.1109/WiSPNET51692.2021.9419464, ISBN 978-1-6654-4086-8, S2CID 232076320
  14. ^ Brauneis, David (1 January 2010). "[OSLC] Possible new Working Group – Automation". open-services.net Community (Mailing list). Archived from the original on 1 September 2018. Retrieved 16 February 2010.
  15. ^ Taylor, Bradley. "Rails Deployment and Automation with ShadowPuppet and Capistrano". Rails machine (blog). Archived from the original on 2 December 2012. Retrieved 16 February 2010.
  16. ^ 예를 들어,
  17. ^ Fowler, Martin. "Practices". Continuous Integration (article). Retrieved 29 November 2015.
  18. ^ Radigan, Dan. "Continuous integration". Atlassian Agile Coach.
  19. ^ "Continuous Integration". Thoughtworks.
  20. ^ Danglot, Benjamin; Monperrus, Martin; Rudametkin, Walter; Baudry, Benoit (5 March 2020). "An approach and benchmark to detect behavioral changes of commits in continuous integration". Empirical Software Engineering. 25 (4): 2379–2415. arXiv:1902.08482. doi:10.1007/s10664-019-09794-7. ISSN 1382-3256. S2CID 67856113.
  21. ^ Ries, Eric (30 March 2009). "Continuous deployment in 5 easy steps". Radar. O’Reilly. Retrieved 10 January 2013.
  22. ^ Fitz, Timothy (10 February 2009). "Continuous Deployment at IMVU: Doing the impossible fifty times a day". Wordpress. Retrieved 10 January 2013.
  23. ^ Laukkanen, Eero (2016). "Problems, causes and solutions when adopting continuous delivery—A systematic literature review". Information and Software Technology. 82: 55–79. doi:10.1016/j.infsof.2016.10.001.
  24. ^ a b c Debbiche, Adam. "Assessing challenges of continuous integration in the context of software requirements breakdown: a case study" (PDF).

외부 링크