지속적 배포 자습서 – Jenkins를 사용하여 지속적 배포 파이프 라인 구축

지속적인 제공 :

Continuous Delivery는 프로덕션 릴리스를 위해 코드 변경이 자동으로 빌드, 테스트 및 준비되는 프로세스입니다.나는 당신이 나의 여기서는 다음 주제에 대해 이야기하겠습니다.

• 지속적 배포 란 무엇입니까?
• 소프트웨어 테스트 유형
• 지속적인 통합, 제공 및 배포의 차이점
• Continuous Delivery의 필요성은 무엇입니까?
• Jenkins 및 Tomcat 사용 실습

Continuous Delivery의 작동 방식을 빠르게 이해하겠습니다.

지속적 배포 란?

언제든지 프로덕션에 릴리스 할 수있는 방식으로 소프트웨어를 빌드하는 프로세스입니다.아래 다이어그램을 고려하십시오.

위의 다이어그램을 설명하겠습니다.

• 자동화 된 빌드 스크립트는 Git과 같은 소스 코드 관리 (SCM)의 변경 사항을 감지합니다.
• 변경 사항이 감지되면 소스 코드가 전용 빌드 서버에 배포되어 빌드가 실패하지 않고 모든 테스트 클래스 및 통합 테스트가 제대로 실행되고 있는지 확인합니다.
• 그런 다음 빌드 애플리케이션이 UAT (User Acceptance Test)를 위해 테스트 서버 (사전 프로덕션 서버)에 배포됩니다.
• 마지막으로 애플리케이션은 릴리스를 위해 프로덕션 서버에 수동으로 배포됩니다.

진행하기 전에 여러 유형의 테스트에 대해 설명하는 것이 공정 할 것입니다.

소프트웨어 테스트 유형 :

일반적으로 두 가지 유형의 테스트가 있습니다.

• 블랙 박스 테스트 : 시스템의 내부 메커니즘을 무시하고 시스템의 입력 및 실행에 대해 생성 된 출력에 초점을 맞추는 테스트 기술입니다. 기능 테스트라고도합니다. 기본적으로 소프트웨어 유효성 검사에 사용됩니다.
• 화이트 박스 테스트 : 시스템의 내부 메커니즘을 고려하는 테스트 기술입니다. 구조 테스트 및 유리 상자 테스트라고도합니다. 기본적으로 소프트웨어 검증에 사용됩니다.

화이트 박스 테스트 :

이 범주에 속하는 두 가지 유형의 테스트가 있습니다.

• 단위 테스트 : 개별 단위 또는 관련 단위 그룹의 테스트입니다. 프로그래머가 구현 한 단위가 주어진 입력에 대해 예상 출력을 생성하는지 테스트하기 위해 종종 수행됩니다.
• 통합 테스트 : 구성 요소 그룹이있는 테스트 유형입니다.결합하여 출력을 생성합니다. 또한 소프트웨어와 하드웨어 구성 요소에 관계가있는 경우 소프트웨어와 하드웨어 간의 상호 작용이 테스트됩니다. 화이트 박스 테스트와 블랙 박스 테스트 모두에 해당 할 수 있습니다.

블랙 박스 테스트 :

이 범주에 속하는 여러 테스트가 있습니다. 나는 집중할 것이다약간이 블로그를 이해하기 위해 알아야 할 중요한 사항 :

• 기능 / 수락 테스트 : 시스템 요구 사항에 필요한 지정된 기능이 작동하는지 확인합니다. 배송 된 제품이 요구 사항을 충족하고 고객이 예상 한대로 작동하는지 확인하기 위해 수행됩니다.
• 시스템 테스트 : 소프트웨어를 다른 환경 (예 : 운영 체제)에 배치하여 계속 작동하도록합니다.
• 스트레스 테스트 : 시스템이 불리한 조건에서 어떻게 작동하는지 평가합니다.
• 베타 테스트 : 최종 사용자, 개발 팀 외부의 팀 또는 다음으로 알려진 제품의 전체 사전 버전을 공개적으로 릴리스하여 수행합니다.베타버전. 베타 테스트의 목적은 예상치 못한 오류를 해결하는 것입니다.

지금이 지속적 통합, 제공 및 배포의 차이점을 설명 할 때입니다.

지속적인 통합, 제공 및 배포의 차이점 :

시각적 콘텐츠는 텍스트 정보보다 빠르고 이해하기 쉬운 방식으로 개인의 두뇌에 도달합니다. 따라서 차이점을 명확하게 설명하는 다이어그램으로 시작하겠습니다.

지속적 통합에서는 모든 코드 커밋이 빌드되고 테스트되지만 릴리스 될 조건이 아닙니다. 즉, UAT (User Acceptance Testing)와 같은 다양한 유형의 블랙 박스 테스트를 사용하여 검증하기 위해 빌드 애플리케이션이 테스트 서버에 자동으로 배포되지 않습니다.

Continuous Delivery에서 애플리케이션은 UAT 용 테스트 서버에 지속적으로 배포됩니다. 또는 애플리케이션이 언제든지 프로덕션에 출시 될 준비가되었다고 말할 수 있습니다. 따라서 지속적 전달을 위해서는 분명히 지속적 통합이 필요합니다.

지속적 배포는 배포 가능한 패키지를 생성하는 것이 아니라 실제로 자동화 된 방식으로 배포하는 지속적 배포의 다음 단계입니다.

표를 사용하여 차이점을 요약하겠습니다.

간단히 말해서 지속적 통합은 지속적 배포 및 지속적 배포의 일부입니다. 지속적 배포는 릴리스가 자동으로 발생한다는 점을 제외하면 지속적 배포와 유사합니다.

Jenkins On Cloud를 사용하여 CI / CD 파이프 라인을 만드는 방법 알아보기

그러나 문제는 지속적인 통합이 충분한 지 여부입니다.

지속적 배포가 필요한 이유

예를 들어 이것을 이해합시다.

80 명의 개발자가 대규모 프로젝트를 진행하고 있다고 상상해보십시오. 자동화 된 빌드를 용이하게하기 위해 지속적 통합 파이프 라인을 사용하고 있습니다. 빌드에는 단위 테스트도 포함되어 있습니다. 어느 날 그들은 단위 테스트를 통과 한 최신 빌드를 테스트 환경에 배포하기로 결정했습니다.

이는 환경 전문가가 수행 한 배포에 대한 길지만 통제 된 접근 방식이어야합니다. 그러나 시스템이 작동하지 않는 것 같습니다.

실패의 명백한 원인은 무엇일까요?

음, 대부분의 사람들이 생각하는 첫 번째 이유는 구성에 문제가 있다는 것입니다. 대부분의 사람들처럼 그들은 그렇게 생각했습니다.그들은 환경 구성의 문제점을 찾으려고 많은 시간을 보냈지 만 문제를 찾지 못했습니다.

한 명의 지각있는 개발자가 현명한 접근 방식을 취했습니다.

그런 다음 수석 개발자 중 한 명이 자신의 개발 컴퓨터에서 응용 프로그램을 사용해 보았습니다. 거기에서도 작동하지 않았습니다.

그는 시스템이 3 주 전에 작동을 멈춘 것을 발견 할 때까지 이전 버전과 이전 버전으로 되돌아갔습니다. 작고 모호한 버그로 인해 시스템이 올바르게 시작되지 않았습니다. 하지만 프로젝트는 단위 테스트 범위가 좋았습니다.그럼에도 불구하고 일반적으로 애플리케이션 자체가 아닌 테스트 만 실행하는 80 명의 개발자는 3 주 동안 문제를 보지 못했습니다.

문제 설명:

프로덕션과 같은 환경에서 수락 테스트를 실행하지 않으면 애플리케이션이 고객의 사양을 충족하는지 또는 실제 환경에서 배포하고 생존 할 수 있는지 여부에 대해 전혀 알지 못합니다. 이러한 주제에 대한시기 적절한 피드백을 원하면 지속적 통합 프로세스의 범위를 확장해야합니다.

위의 문제를보고 배운 교훈을 요약하겠습니다.

• 단위 테스트는 문제 해결에 대한 개발자의 관점 만 테스트합니다. 그들은 응용 프로그램이 사용자 관점에서 예상되는 작업을 수행한다는 것을 증명할 수있는 제한된 능력 만 가지고 있습니다. 그들은 충분하지 않습니다실제 기능 문제를 식별합니다.
• 테스트 환경에 애플리케이션을 배포하는 것은 복잡하고 수작업이 많은 프로세스로 오류가 발생하기 쉽습니다.즉, 모든 배포 시도는 오류가 발생하기 쉬운 수동 프로세스라는 새로운 실험이었습니다.

솔루션 – 지속적 전달 파이프 라인 (자동 수락 테스트) :

그들은 지속적 통합 (지속적 전달)을 다음 단계로 가져 갔고 애플리케이션이 실행되고 가장 기본적인 기능을 수행 할 수 있음을 입증하는 몇 가지 간단하고 자동화 된 수락 테스트를 도입했습니다.수락 테스트 단계에서 실행되는 대부분의 테스트는 기능 수락 테스트입니다.

기본적으로 프로덕션 서버의 복제 본인 테스트 서버에 배포 할 때 애플리케이션이 제대로 작동하는지 확인하여 애플리케이션이 프로덕션 환경에 원활하게 배포되도록하기 위해 지속적 배포 파이프 라인을 구축했습니다.

이론이 충분하므로 이제 Jenkins를 사용하여 지속적 배포 파이프 라인을 만드는 방법을 보여 드리겠습니다.

Jenkins를 사용한 지속적 배포 파이프 라인 :

여기서는 Jenkins를 사용하여 다음 작업을 포함하는 Continuous Delivery Pipeline을 만들 것입니다.

데모에 관련된 단계 :

• GitHub에서 코드 가져 오기
• 소스 코드 컴파일
• 단위 테스트 및 JUnit 테스트 보고서 생성
• 애플리케이션을 WAR 파일로 패키징하고 Tomcat 서버에 배치

전제 조건 :

• CentOS 7 시스템
• 젠킨스 2.121.1
• Docker
• 톰캣 7

단계 – 1 소스 코드 컴파일 :

먼저 Jenkins에서 Freestyle 프로젝트를 만들어 보겠습니다. 아래 스크린 샷을 고려하십시오.

프로젝트에 이름을 지정하고 Freestyle Project를 선택합니다.

아래로 스크롤하면 소스 코드 저장소를 추가하고 git을 선택하고 저장소 URL을 추가하는 옵션을 찾을 수 있습니다. 해당 저장소에는 프로젝트를 빌드하는 데 사용할 pom.xml 파일이 있습니다. 아래 스크린 샷을 고려하십시오.

이제 빌드 트리거를 추가합니다. poll SCM 옵션을 선택합니다. 기본적으로 코드 변경 사항에 대해 5 분마다 GitHub 저장소를 폴링하도록 Jenkins를 구성합니다. 아래 스크린 샷을 고려하십시오.

계속 진행하기 전에 Maven 빌드주기에 대해 간략하게 소개하겠습니다.

각 빌드 수명주기는 서로 다른 빌드 단계 목록으로 정의되며, 여기서 빌드 단계는 수명주기의 단계를 나타냅니다.

다음은 빌드 단계 목록입니다.

• 검증 – 프로젝트가 정확하고 필요한 모든 정보를 사용할 수 있는지 검증합니다.
• 컴파일 – 프로젝트의 소스 코드를 컴파일
• 테스트 – 적절한 단위 테스트 프레임 워크를 사용하여 컴파일 된 소스 코드를 테스트합니다. 이러한 테스트에서는 코드를 패키지화하거나 배포 할 필요가 없습니다.
• package – 컴파일 된 코드를 가져와 JAR과 같은 배포 가능한 형식으로 패키징합니다.
• 검증 – 통합 테스트 결과에 대한 검사를 실행하여 품질 기준이 충족되는지 확인합니다.
• install – 로컬 저장소에 패키지를 설치하여 다른 프로젝트에서 로컬로 종속성으로 사용합니다.
• 배포 – 빌드 환경에서 수행되며 최종 패키지를 원격 저장소에 복사하여 다른 개발자 및 프로젝트와 공유합니다.

소스 코드를 컴파일하고 단위 테스트를 수행하고 애플리케이션을 war 파일로 패키징하기 위해 아래 명령을 실행할 수 있습니다.

mvn 클린 패키지

빌드 작업을 여러 빌드 단계로 나눌 수도 있습니다. 이렇게하면 깔끔하고 별도의 단계에서 빌드를 더 쉽게 구성 할 수 있습니다.

그래서 우리는 소스 코드를 컴파일하는 것으로 시작할 것입니다. 빌드 탭에서 상위 레벨 maven 대상 호출을 클릭하고 아래 명령을 입력하십시오.

자바 예제 프로그램에서 케이스 전환

엮다

아래 스크린 샷을 고려하십시오.

이렇게하면 GitHub 저장소에서 소스 코드를 가져 와서 컴파일 (Maven 컴파일 단계)합니다.

저장을 클릭하고 프로젝트를 실행하십시오.

이제 콘솔 출력을 클릭하여 결과를 확인하십시오.

단계 – 2 단위 테스트 :

이제 단위 테스트를위한 Freestyle Project를 하나 더 만들 것입니다.

이전 작업에서했던 것처럼 소스 코드 관리 탭에 동일한 저장소 URL을 추가합니다.

이제 'Buid Trigger'탭에서 '다른 프로젝트가 빌드 된 후 빌드'를 클릭합니다. 소스 코드를 컴파일하는 이전 프로젝트의 이름을 입력하고 아래 옵션 중 하나를 선택할 수 있습니다.

• 빌드가 안정적인 경우에만 트리거
• 빌드가 불안정한 경우에도 트리거
• 빌드가 실패하더라도 트리거

위의 옵션은 자명하다고 생각하므로 하나를 선택하십시오. 아래 스크린 샷을 고려하십시오.

빌드 탭에서 최상위 레벨 maven 대상 호출을 클릭하고 아래 명령을 사용하십시오.

테스트

Jenkins는 또한 테스트 결과 및 테스트 결과 추세를 표시하는 데 도움을줍니다.

Java 세계에서 테스트보고를위한 사실상의 표준은 JUnit에서 사용하는 XML 형식입니다. 이 형식은 TestNG, Spock 및 Easyb와 같은 다른 많은 Java 테스트 도구에서도 사용됩니다. Jenkins는이 형식을 이해하므로 빌드가 JUnit XML 테스트 결과를 생성하는 경우 Jenkins는 시간이 지남에 따라 멋진 그래픽 테스트 보고서와 테스트 결과에 대한 통계를 생성하고 테스트 실패에 대한 세부 정보를 볼 수 있습니다. Jenkins는 또한 테스트 실행에 걸리는 시간을 전 세계적으로 그리고 테스트별로 추적합니다. 성능 문제를 추적해야하는 경우 유용 할 수 있습니다.

따라서 다음으로해야 할 일은 Jenkins가 단위 테스트를 계속 확인하도록하는 것입니다.

빌드 후 작업 섹션으로 이동하여 'JUnit 테스트 결과 보고서 게시'확인란을 선택합니다. Maven이 프로젝트에서 단위 테스트를 실행하면 surefire-reports라는 디렉토리에 XML 테스트 보고서가 자동으로 생성됩니다.. 따라서 'Test report XMLs'필드에 '** / target / surefire-reports / *. xml'을 입력합니다. 경로 시작 부분에있는 두 개의 별표 ( '**')는 구성을 좀 더 견고하게 만드는 모범 사례입니다. 소스 코드를 확인하도록 Jenkins를 구성한 방법에 관계없이 Jenkins가 대상 디렉터리를 찾을 수 있도록합니다.

** / target / surefire-reports / *. xml

다시 저장하고 지금 빌드를 클릭하십시오.

이제 JUnit 보고서는 / var / lib / jenkins / workspace / test / gameoflife-core / target / surefire-reports / TEST-behavior에 작성됩니다.

Jenkins 대시 보드에서테스트 결과를 확인할 수도 있습니다.

단계 – 3 WAR 파일 생성 및 Tomcat 서버에 배포 :

이제 다음 단계는 애플리케이션을 WAR 파일로 패키징하고 사용자 승인 테스트를 위해 Tomcat 서버에 배포하는 것입니다.

자유형 프로젝트를 하나 더 만들고 소스 코드 저장소 URL을 추가합니다.

그런 다음 빌드 트리거 탭에서 다른 프로젝트가 빌드 될 때 빌드를 선택하고 아래 스크린 샷을 고려하십시오.

기본적으로 테스트 작업 후 배포 단계가 자동으로 시작됩니다.

빌드 탭에서 쉘 스크립트를 선택하십시오. 아래 명령을 입력하여 애플리케이션을 WAR 파일로 패키징하십시오.

mvn 패키지

다음 단계는이 WAR 파일을 Tomcat에 배포하는 것입니다.섬기는 사람. 'Post-Build Actions'탭에서 컨테이너에 war / ear 배포를 선택합니다. 여기에서 war 파일의 경로를 제공하고 컨텍스트 경로를 제공하십시오. 아래 스크린 샷을 고려하십시오.

Tomcat 자격 증명을 선택하고 위의 스크린 샷을 확인합니다. 또한 Tomcat 서버의 URL을 제공해야합니다.

Jenkins에서 자격 증명을 추가하려면 Jenkins 대시 보드에서 자격 증명 옵션을 클릭합니다.

시스템을 클릭하고 글로벌 자격 증명을 선택합니다.

그런 다음 자격 증명을 추가하는 옵션을 찾을 수 있습니다. 그것을 클릭하고 자격 증명을 추가하십시오.

Tomcat 자격 증명을 추가하고 아래 스크린 샷을 고려하십시오.

확인을 클릭하십시오.

이제 프로젝트 구성에서 이전 단계에서 삽입 한 tomcat 자격 증명을 추가합니다.

저장을 클릭 한 다음 지금 빌드를 선택합니다.

컨텍스트 경로와 함께 tomcat URL로 이동합니다. 제 경우에는 http : // localhost : 8081입니다. 이제 마지막에 컨텍스트 경로를 추가하고 아래 스크린 샷을 고려하십시오.

링크-http : // localhost : 8081 / gof

컨텍스트 경로의 의미를 이해 하셨기를 바랍니다.

이제 파이프 라인보기를 생성하고 아래 스크린 샷을 고려하십시오.

더하기 아이콘을 클릭하여 새보기를 만듭니다.

원하는 방식으로 파이프 라인을 구성하고 아래 스크린 샷을 고려하십시오.

나는 초기 직업을 선택하는 것 외에 아무것도 변경하지 않았습니다. 따라서 내 파이프 라인은 컴파일에서 시작됩니다. 다른 작업을 구성한 방식에 따라 컴파일 후 테스트 및 배포가 발생합니다.

마지막으로 실행을 클릭하여 파이프 라인을 테스트 할 수 있습니다. 5 분마다 소스 코드가 변경되면 전체 파이프 라인이 실행됩니다.

따라서 UAT (사용자 승인 테스트)를 위해 테스트 서버에 애플리케이션을 지속적으로 배포 할 수 있습니다.

Continuous Delivery에 대한이 게시물을 즐겁게 읽으 셨기를 바랍니다. 궁금한 점이 있으시면 아래 댓글란에 남겨 주시면 빠른 시일 내에 답변 드리겠습니다.

CI / CD 파이프 라인을 구축하려면 다양한 기술을 습득해야합니다. 지금 필요한 DevOps 기술 마스터