🥇참조: 지속적 통합 프로세스의 작동 방식

오늘은 용어의 역사를 살펴보고, CI 구현의 어려움에 대해 논의하고, CI 작업에 도움이 되는 몇 가지 널리 사용되는 도구를 제공하겠습니다.

기간

지속적인 통합은 빈번한 프로젝트 빌드 및 코드 테스트를 포함하는 애플리케이션 개발에 대한 접근 방식입니다.

목표는 통합 프로세스를 예측 가능하게 만들고 잠재적인 버그와 오류를 초기 단계에서 감지하여 수정하는 데 더 많은 시간을 확보하는 것입니다.

지속적인 통합이라는 용어는 1991년에 처음 등장했습니다. UML 언어 창시자가 소개했습니다. 그래디 부치 (그레이디 부치). 엔지니어는 자신의 개발 관행의 일부로 CI 개념을 도입했습니다. 부흐 방식. 이는 객체 지향 시스템을 설계할 때 아키텍처의 점진적인 개선을 의미했습니다. Gradi는 지속적인 통합에 대한 요구 사항을 설명하지 않았습니다. 그러나 나중에 그의 책에서 “애플리케이션을 이용한 객체지향 분석 및 설계“그는 방법론의 목표가 “내부 릴리스”의 출시 속도를 높이는 것이라고 말했습니다.

이야기

1996년에 CI는 방법론 창시자들에 의해 채택되었습니다. 익스트림 프로그래밍 (XP) - 켄트 벡 (켄트 벡) 그리고 론 제프리스 (론 제프리). 지속적인 통합은 접근 방식의 XNUMX가지 핵심 원칙 중 하나가 되었습니다. XP 창립자들은 CI 방법론에 대한 요구 사항을 명확히 하고 하루에 여러 번 프로젝트를 구축해야 한다는 점을 지적했습니다.

2000년대 초반 Agile Alliance의 창립자 중 한 명이 지속적인 통합 방법론을 홍보하기 시작했습니다. 마틴 파울러 (마틴 파울러). CI에 대한 그의 실험은 이 분야 최초의 소프트웨어 도구인 CruiseControl로 이어졌습니다. 이 유틸리티는 Martin의 동료인 Matthew Foemmel이 만들었습니다.

도구의 빌드 주기는 버전 제어 시스템에서 코드 베이스의 변경 사항을 주기적으로 확인하는 데몬으로 구현됩니다. 솔루션은 오늘 다운로드할 수 있습니다. 배포자 BSD와 유사한 라이센스에 따라.

CI용 소프트웨어가 등장하면서 점점 더 많은 기업이 CI를 채택하기 시작했습니다. Forrester 조사에 따르면 [5페이지 보고], 2009년에는 조사 대상 86개 기술 기업 중 XNUMX%가 CI 방법을 사용하거나 구현했습니다.

오늘날 지속적 통합의 관행은 다양한 산업 분야의 조직에서 사용됩니다. 2018년 한 대형 클라우드 제공업체는 서비스, 교육, 금융 부문 기업의 IT 전문가를 대상으로 설문조사를 실시했습니다. 58명의 응답자 중 XNUMX%가 업무에 CI 도구와 원칙을 사용한다고 답했습니다.

이거 어떻게 작동 시켜요

지속적인 통합은 버전 제어 시스템과 CI 서버라는 두 가지 도구를 기반으로 합니다. 후자는 물리적 장치일 수도 있고 클라우드 환경의 가상 머신일 수도 있습니다. 개발자는 하루에 한 번 이상 새 코드를 업로드합니다. CI 서버는 이를 모든 종속성과 함께 자동으로 복사하고 빌드합니다. 그런 다음 통합 및 단위 테스트를 실행합니다. 테스트가 성공적으로 통과되면 CI 시스템이 코드를 배포합니다.

일반적인 프로세스 다이어그램은 다음과 같이 나타낼 수 있습니다.

CI 방법론은 개발자에게 여러 가지 요구 사항을 제시합니다.

문제를 즉시 수정하세요. 이 원칙은 익스트림 프로그래밍에서 CI로 왔습니다. 버그 수정은 개발자의 최우선 과제입니다.
프로세스를 자동화합니다. 개발자와 관리자는 통합 프로세스에서 병목 현상을 지속적으로 찾아 제거해야 합니다. 예를 들어 통합에 병목 현상이 발생하는 경우가 많습니다. 밝혀지다. 테스트.
가능한 한 자주 집회를 진행하십시오. 하루에 한 번 팀 작업을 동기화합니다.

구현의 어려움

첫 번째 문제는 높은 운영 비용입니다. 회사가 개방형 CI 도구(나중에 설명)를 사용하더라도 여전히 인프라 지원에 비용을 지출해야 합니다. 그러나 클라우드 기술이 해결책이 될 수 있습니다.

다양한 규모의 컴퓨터 구성 조립을 단순화합니다. 회사의 플러스 돈을 받다. 사용된 리소스에 대해서만 인프라를 절약하는 데 도움이 됩니다.

설문 조사에 따르면 [페이지 14 조항], 지속적인 통합은 (적어도 처음에는) 회사 직원의 부담을 증가시킵니다. 그들은 새로운 도구를 배워야 하며, 동료들이 항상 훈련을 도와주는 것은 아닙니다. 따라서 새로운 프레임워크와 서비스를 즉석에서 처리해야 합니다.

세 번째 어려움은 자동화 문제입니다. 자동화된 테스트에서 다루지 않는 레거시 코드가 많은 조직은 이 문제에 직면합니다. 이로 인해 CI가 완전히 구현되기 전에 코드가 단순히 다시 작성된다는 사실이 발생합니다.

/플리커/ 그 사람 / CC의 BY-SA

누가 사용

IT 대기업들은 이 방법론의 이점을 가장 먼저 인식한 기업 중 하나입니다. Google использует 2000년대 중반 이후 지속적인 통합. 검색 엔진의 지연 문제를 해결하기 위해 CI가 구현되었습니다. 지속적인 통합은 문제를 신속하게 감지하고 해결하는 데 도움이 되었습니다. 이제 CI는 거대 IT 기업의 모든 부서에서 사용됩니다.

지속적인 통합은 소규모 기업에도 도움이 되며, CI 도구는 금융 및 의료 기관에서도 사용됩니다. 예를 들어, Morningstar에서는 지속적인 통합 서비스를 통해 취약점을 70% 더 빠르게 패치할 수 있었습니다. 또한 Philips Healthcare 의료 플랫폼은 업데이트 테스트 속도를 두 배로 높일 수 있었습니다.

도구

CI에 널리 사용되는 도구는 다음과 같습니다.

젠킨스 가장 널리 사용되는 CI 시스템 중 하나입니다. 다양한 VCS, 클라우드 플랫폼 및 기타 서비스와의 통합을 위해 수천 개가 넘는 플러그인을 지원합니다. 1cloud에서는 Jenkins도 사용합니다. 도구 DevOps 시스템에 포함됨. 그는 정기적으로 테스트용 Git 브랜치를 확인합니다.
빌드 봇 — 자신만의 지속적인 통합 프로세스를 작성하기 위한 Python 프레임워크입니다. 도구의 초기 설정은 매우 복잡하지만 다양한 사용자 정의 옵션으로 보완됩니다. 프레임워크의 장점 중 사용자는 낮은 리소스 집약도를 강조합니다.
콩 코스 CI Docker 컨테이너를 사용하는 Pivotal의 서버입니다. Concourse CI는 모든 도구 및 버전 제어 시스템과 통합됩니다. 개발자는 이 시스템이 모든 규모의 회사에서 작업하는 데 적합하다고 지적합니다.
깃랩 CI GitLab 버전 제어 시스템에 내장된 도구입니다. 서비스는 클라우드에서 실행되며 구성을 위해 YAML 파일을 사용합니다. Concourse, Gitlab CI와 마찬가지로 적용 다양한 프로세스를 서로 격리하는 데 도움이 되는 Docker 컨테이너입니다.
코드 십 GitHub, GitLab 및 BitBucket과 함께 작동하는 클라우드 CI 서버입니다. 플랫폼은 긴 초기 설정이 필요하지 않습니다. 사전 설치된 표준 CI 프로세스를 Codeship에서 사용할 수 있습니다. 소규모(월 최대 100개 빌드) 및 오픈 소스 프로젝트의 경우 Codeship을 무료로 사용할 수 있습니다.

당사 블로그의 자료:

출처 : habr.com

참조: 지속적 통합 프로세스의 작동 방식

기간

이야기

이거 어떻게 작동 시켜요

구현의 어려움

누가 사용

도구

당사 블로그의 자료:

코멘트를 추가 답장을 취소