목차

    젠킨스 파이프 라인이란?

    젠킨스 파이프 라인이란 연속적인 작업들을 젠킨스에서 파이프라인(작업)으로 묶어서 관리할 수 있게 만드는 플러그인이다.

    CI/CD

    CI(Continue Integration) 즉, 지속적인 통합이라는 의미이다. 지속적인 통합이란, 어플리케이션의 소스 변경 사항이 정기적으로 빌드 및 테스트되어 공유 레파지토리에 통합하는 것을 의미한다.

    지속적인 통합이란, 어플리케이션의 소스 변경 사항이 정기적으로 빌드 및 테스트되어 공유 레파지토리에 통합하는 것을 의미한다,

    CD(Continueous Delivery) 혹은 Continuous Deployment 두 용어 모두의 축약어이다.

    전자인, Continuous Delivery는 공유 레파지토리로 자동으로 Release하는 것을 의미하며, 지속적인 서비스 제공을 뜻한다.

    후자인, Continuous Deployment는 Production 레벨까지 자동으로 deploy 하는 것을 의미하며, 고객에게 배포하는 것을 뜻한다.

     

    정리하면, 

    CI는 애플리케이션 소스를 빌드 테스트, 병합하는 것을 의미하고, 

    CD는 개발자의 변경사항이 레파지토리르 넘어, 고객에게 배포하는 것까지를 의미한다.

     

    Pipeline 정의

    • 1) Pipeline script : 위의 사진과 같이 Jenkins내에서 Script를 작성하여 Pipeline을 구성한다. Jenkins내에서 작성을 하기 때문에 간편하다는 이점이 있다.
    • 2) Pipeline script from SCM : SCM은 Git이나 SVN과 같이 형상관리툴을 의미하며, 소스쪽에 Jenkins 파일을 생성하여 별도로 Script를 작성하여 구성하는 방식이다. 보안상의 이점이 있기때문에 이 방식을 많이 사용한다.

    pipeline source

    node {
      stage 'Setting'
      def javaHome = tool name: 'jdk8', type: 'hudson.model.JDK'
      env.JAVA_HOME = "${javaHome}"
      env.PATH = "${env.PATH}:${env.JAVA_HOME}/bin"
    
      // github에서 소스 얻어오기
      stage 'Checkout'
      git branch: 'master', credentialsId: 'Your Credentials ID', url: 'Your GitHub URL'
    
      // Maven으로 빌드 실행하기
      stage 'Build'
      def mvnHome = tool 'M3'
        sh "'${mvnHome}/bin/mvn' -Dmaven.test.skip=true clean install"
      // 패키지 저장
      step([$class: 'ArtifactArchiver', artifacts: '**/target/*.jar', fingerprint: true])
      
      // 서버실행 
      //stage 'Start'
        //sh "java -jar C:/ProgramData/Jenkins/.jenkins/workspace/test-pipeline/target/hr-0.0.1-SNAPSHOT.jar"
    }

    Script 통해 Setting, Checkout, Build, Start라는 단계별 Stage 정의하였으며,  Stage들이 모여 CI/CD 진행시키는 하나의 pipeline 구축한 것이다.

     

    파이프 라인 활용

    • 같은 Job인데 파라미터 혹은 스케줄만 다르게 하고 싶을 때? 파이프라인!
    • 여러 Job을 순서대로 실행하지만 가끔은 개별로도 실행이 필요할 때? 파이프라인!
    • 스프링 배치에서 여러 작업을 순차적으로 실행할 때 Step으로 나누기보다는 파이프 라인을 우선 고려!
      • 처음엔 그럴 경우가 없다고 생각하더라도 혹시 이후에 요구사항이 바뀔 수 있으니까 고려해보는 것이 좋음.

    'Back-end > 젠킨스CICD' 카테고리의 다른 글

    [Maven] Artifact / maven-war-plugin / SNAPSHOT  (0) 2021.11.15
    메이븐(Maven) - 개념  (0) 2021.01.29

    Artifact
    Maven등에서 빌드 결과로 나오는 개발 산출물을 주로 Artifact라고 합니다. 또한 Java외에 기타 다른 다양한 '산출물'을 Artifact라고 부르며, Delivery 및 Deploy를 위해 최종적으로 관리되는 산출물이라고 생각하면 된다. Artifact를 모아서 저장하는 공간을 Library 또는 Artifactory라고 한다.

    Maven-war-plugin

    Maven-war-plugin
    pom.xml의 dependency에 선언된 각종 라이브러리들과 Java class 파일 웹 어플리케이션의 각종 리소스들을 모아서 하나의 Web Application Archive 압축 파일로 만들어 줍니다.
    war:war
    war 형태의 압축 파일로 빌드하는 명령입니다. 압출 파일은 WAS에 의해 압축이 풀리고 파일이 많은 경우에는 압축 해제 시간이 오래 걸릴 수 있습니다.
    war:exploded
    war 압축 형태를 해체한 디렉토리 형태 구조로 빌드하는 명령입니다. 압축 및 해제 과정이 불필요하고 별도의 디렉토리에 원본 소스를 복사하여 만듭니다. 원본 소스를 건드리지 않고 배포를 원하는 경우에 적합합니다.
    war:inplace
    target 디렉토리 뿐만 아니라 다른 디렉토리에 library와 class 파일들이 생성되도록 하는 명령입니다. 기본적으로 src/main/webapp이 지정되어 있습니다.

    각각의 구조


    SNAPSHOT이란?

    SNAPSHOT
    아직 릴리즈 되지 않은 버전을 뜻한다. 실제(릴리즈)버전과 스냅 샷 버전의 차이점은 스냅 샷에 업데이트가 있을 수 있다는 것이다. 즉, 1.0-SNAPSHOT 오늘 다운로드하면 어제 나 내일 다운로드하는 것과 다른 파일이 제공될 수 있다.
    ex) foo-1.0.jar는 maven이 로컬 저장소에서 라이브러리를 찾으면 현재 빌드에 이 라이브러리를 사용합니다.(만약 안정적이지 않다면 setting.xml 또는 pom.xml)을 검색하여 종속성을 검색합니다. 
    (안정적이지 않다 = foo-1.0.SNAPSHOT.jar와 같은 것을 의미한다.)

     

    'Back-end > 젠킨스CICD' 카테고리의 다른 글

    젠킨스 파이프라인 구성(jenkins Pipeline)  (0) 2022.04.05
    메이븐(Maven) - 개념  (0) 2021.01.29

    Maven이란?

    Maven은 자바 프로젝트의 빌드(build)를 자동화 해주는 빌드 툴(Build tool) 이다. 즉, 자바소스를 compile하고 package해서 deploy하는 일을 자동화 해주는 것이다. 

     

    Maven이 참조하는 설정 파일

    Maven 전체를 보기보다 프로그래밍에 직접적인 연관이 있는 두 개 의 설정 파일을 알아보면 된다.

    • settings.xml
      • settings.xml은 maven tool 자체에 관련된 설정을 담당한다. MAVEN_HOME\conf\ 아래에 있는 설정이다. ( MAVEN_HOEM은 환경변수에 설정한 경로) Maven 자체에 설정 값을 바꾸는 일은 일단 잘 없다.
    • pom.xml
      • 하나의 자바 프로젝트에 빌드 툴로 maven을 설정했다면, 프로젝트 최상위 디렉토리에 "pom.xml"이라는 파일이 생성되었을 것이다. 
      • pom.xml은 POM(Project Object Model)을 설정하는 부분으로 프로젝트 내 빌드 옵션을 설정하는 부분이다.
      • 꼭 pom.xml이라는 이름을 가진 파일이 아니라 다른 파일로 지정할 수도 있다. (mvn -f ooo.xml test)
      • 그러나 maven의 원칙으로 다른 개발자들이 헷갈릴 수 있으므로 그냥 pom.xml으로 쓰기를 권장한다.
    <?xml version="1.0" encoding="UTF-8"?>
    <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
        /*maven의 pom.xml의 모델 버전이다. 형식이 4.0.0 버전이라고 생각하면 된다.*/
        <modelVersion>4.0.0</modelVersion>
        
     	/*groupId 프로젝트를 생성한 조직 또는 그룹명으로 보통, URL의 역순으로 지정한다.*/
        <groupId>com.example</groupId>
        
        /*프로젝트에서 생성되는 기본 아티팩트의 고유 이름이다.*/
        <artifactId>demo</artifactId>
        /*SNAPSHOT이 붙으면 아직 개발단계를 의미한다.*/
        <version>0.0.1-SNAPSHOT</version>
        /*jar, war, ear, pom등 패키지 유형을 나타낸다. */
        <packaging>jar</packaging>
     	/*프로젝트명*/
        <name>demo</name>
        /*프로젝트 설명*/
        <description>Demo project for Spring Boot</description>
      
        <parent>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-parent</artifactId>
            <version>2.0.5.RELEASE</version>
            <relativePath/> <!-- lookup parent from repository -->
        </parent>
     
        <properties>
            <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
            <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
            <java.version>1.8</java.version>
        </properties>
     
     	/* 의존성 라이러리 정보 최소한 groupId, artifactId, version 정보가 필요하다 */
        <dependencies>
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter-web</artifactId>
            </dependency>
     
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-devtools</artifactId>
                /*ompile, runtime, provided, test등이 올 수 있는데 
                해당 라이브러리가 언제 필요한지 언제 제외되는지를 나태는것으로 따로 검색 해보면 알 수 있다.*/
                <scope>runtime</scope>
            </dependency>
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter-test</artifactId>
                <scope>test</scope>
            </dependency>
        </dependencies>
     
     	/* 빌드정보
        build tool : maven의 핵심인 빌드와 관련된 정보를 설정할 수 있는 곳이다.*/
        <build>
            <plugins>
                <plugin>
                    <groupId>org.springframework.boot</groupId>
                    <artifactId>spring-boot-maven-plugin</artifactId>
                </plugin>
            </plugins>
        </build>
    </project>
     

     

    메이븐의 모든 기능은 플러그인(plug-in)을 기반으로 동작한다.

    플러그인에서 실행할 수 있는 각각의 작업을 골(goal)이라고 하나의 페이즈는 하나의 골과 연결되며, 하나의 플러그인에는 여러개의 골이 있을 수 있다.

     

    * 라이프 사이클

    mvn process-resources : resources:resources의 실행으로 resource 디렉토리에 있는 내용을 target/classes로 복사한다.
    mvn compile : compiler:compile의 실행으로 src/java 밑의 모든 자바 소스를 컴파일해서 target/classes로 복사
    mvn process-testResources, mvn test-compile : 이것은 위의 두 개가 src/java였다면 test/java의 내용을 target/test-classes로 복사. (참고로 test만 mvn test 명령을 내리면 라이프사이클상 원본 소스로 컴파일된다.)
    mvn test : surefire:test의 실행으로 target/test-classes에 있는 테스트케이스의 단위테스트를 진행한다. 결과를 target/surefire-reports에 생성한다.
    mvn package : target디렉토리 하위에 jar, war, ear등 패키지파일을 생성하고 이름은 <build>의 <finalName>의 값을 사용한다 지정되지 않았을 때는 아까 설명한 "artifactId-version.extention" 이름으로 생성
    mvn install : 로컬 저장소로 배포
    mvn deploy : 원격 저장소로 배포
    mvn clean : 빌드 과정에서 생긴 target 디렉토리 내용 삭제
    mvn site : target/site에 문서 사이트 생성
    mvn site-deploy : 문서 사이트를 서버로 배포
    위와 같은 진행 순서로 라이프 사이클이 진행된다. 

    * build 설정 값

    이제 <build>에서 설정할 수 있는 값을 확인해보자.
    <finalName> : 빌드 결과물(ex .jar) 이름 설정
    <resources> : 리소스(각종 설정 파일)의 위치를 지정할 수 있다.

    - <resource> : 없으면 기본으로 "src/main/resources"

    <testResources> : 테스트 리소스의 위치를 지정할 수 있다.

    - <testResource> : 없으면 기본으로 "src/test/resources"

    : 빌드할 때 접근할 저장소의 위치를 지정할 수 있다. 기본적으로 메이븐 중앙 저장소인 http://repo1.maven.org/maven2로 지정되어 있다.

    <outputDirectory> : 컴파일한 결과물 위치 값 지정, 기본 "target/classes"

    <testOutputDirectory> : 테스트 소스를 컴파일한 결과물 위치 값 지정, 기본 "target/test-classes"

    <plugin> : 어떠한 액션 하나를 담당하는 것으로 가장 중요하지만 들어가는 옵션은 제 각각이다. 다행인 것은 플러그인 형식에 대한 것은 안내가 나와있으니 그것을 참고해서 작성하면 된다.

    plugin이 작성되어 있다고 무조건 실행되는 것은 아니다. 명확한 것은 아니지만 따로 실행할 플러그인을 메이븐 명령어로 실행해야 하는 것으로 알고 있다.

    - <executions> : 플러그인 goal과 관련된 실행에 대한 설정

    - <configuration> : 플러그인에서 필요한 설정 값 지정

    apache CXF를 이용한 code generate 플러그인은 아래에서 소개되고 사용한다.

    + Recent posts