이전 포스팅에 이어 Jenkins&GitHub을 이용한 CI 실습을 다루어볼 것이다. 이번 포스팅에서는 본격적으로 실습을 진행하기 전에 아주 간단한 echo를 찍어주는 pipeline 하나를 만들어 볼 것이다. 사실 이것을 설명하는 이유는 멀티브랜치 파이프라인에 대해 조금 이해해보기 위함이다.

1. Multibranch Pipeline 생성

사실 우리가 개발할때, 버전관리 시스템에서 브랜치를 하나만 사용하여 개발하지 않는다. 각 회사마다의 브랜치 전략이 있겠지만 가장 대중적인 브랜치 전략은 아래와 같다.

• Feature branch
• Integration branch
• Master branch(production branch)

이렇게 여러개의 브랜치를 가지고 개발을 진행하고 이러한 멀티 브랜치 전략에 대해 Jenkins를 이용하여 CI를 구현할때는 Multibranch Pipeline을 이용한다. 자세한 브랜치 전략은 구글링해서 참고하자 ㅎㅎ.

새로운 Item 메뉴를 클릭하면 다음과 같은 페이지가 보일 것이다.

item 이름을 넣고 Multibranch Pipeline을 생성해준다. 하나 설명하면 Multibranch Pipeline은 직접 스크립트를 Jenkins에서 작성하지 않고 소스코드가 있는 Github project root에 Jenkinsfile로 정의된다. Jenkinsfile은 쉽게 말하면 파이프라인 스크립트가 정의된 파일로 보면 된다.

Branch Sources 탭을 클릭하여 필요한 정보를 기입할 것이다. 지금은 자세한 설명보다는 파이프라인이 동작하는 것을 집중적으로 볼 것이기 때문에 정말 필요한 정보만 기입한다.

Repository HTTPS URL에 생성한 GitHub 레포지토리 주소를 기입한다. Discover branches 의 Strategy를 All branches로 바꿔준다. Add 버튼을 클릭하고 Filter by name (with wildcards)를 추가한다. 그리고 Include에 master develop을 입력한다. 여기까지 작성하고 save해준다.

다음으로 간단하게 springboot project를 생성하고 해당 프로젝트 root에 Jenkinsfile을 생성해준다. 소스코드는 아래 깃헙 정보를 참고하자

2. Jenkinsfile 작성

간단하게 Jenkinsfile을 작성해보자. 샘플은 위 깃헙에 있으니 내려받아도 무방하다.

pipeline {
    agent none

    stages {
        stage('example build') {
            steps {
                echo 'jenkins sample build ! ${AUTHOR}'
            }
        }
    }
    post {
        always {
            echo 'post process !'
        }
    }
}

여기까지 작성한 후 master branch를 기준으로 develop branch를 하나 딴 후에 간단히 수정 후 커밋&푸시 해보자 ! 우리는 이전 포스팅에서 "GitHub의 master와 develop 브랜치의 PR, push를 인식시킨다." 라는 설정을 넣었기 때문에 Jenkins pipeline이 돌기를 기대해야한다. 과연 파이프라인이 작동하였을까?

오?! 뭔가 돌았다?(필자는 테스트로 한번 더 돌려서 2개가 보인다.) #1을 클릭한 후에 정말 잘 돌았는지 Console Output을 보자 !

오호 우리가 정의한 파이프라인이 작동했다 ! 정말 신기방기하다. 정말 간단한 것이지만 여기까지 진행했다면 Jenkins&GitHub을 이용한 CI의 느낌을 어느정도 느꼈을 것이다. 그리고 조금더 감각있는 사람은 앞으로 어떠한 실습을 진행할지 예상도 될것이다. 여기까지 간단하게 멀티브랜치 파이프라인 실습을 마친다. 다음 포스팅부터는 본격적으로 실무적인 레벨의 실습을 다루어본다.

3. 지금까지 다룬것

1. CentOS 환경에서 Docker로 Jenkins 설치
2. Jenkins와 GitHub 연동
3. develop branch로 수정한 후 커밋&푸시를 통해 간단한 멀티브랜치 파이프라인 동작확인

아래 명령어는 특정 브랜치만 clone하는 방법이다.

git clone -b {branch_name} --single-branch {git_repository_host}

GitHub - Git 사용법 2 (branch, checkout, reset 등)

이전 포스팅에서는 간단한 Git 사용법에 대하여 다루어봤습니다. 이번에는 조금 더 나아가서 branch, tag, 잘못 반영된 작업을 되돌리는 작업 등 조금 더 진화된 예제를 다루어보려고합니다. 혹시 이전 포스팅을 보시지 못하셨다면 이전 포스팅을 참고하시고 오시면 좋을 듯 싶습니다. 혹시라도 대부분의 기본 명령어들이 숙지 되어있으시다면 굳이 보시지 않으셔도 됩니다.

▶︎▶︎▶︎GitHub - 간단한 Git사용법(로컬 레포지토리,원격 레포지토리)

로컬 레포지토리에서 잘못 반영되어 되돌리고싶을때(Checkout OR Reset,Fetch)

만약 commit하지 않았다면 "git checkout -- filename"으로 변경내용을 변경 전 상태(HEAD)로 되돌려줍니다.

다만, 이미 인덱스에 추가된 변경 내용과 새로 생성한 파일은 그대로 남습니다.

but add 하지않아서 index에 들어가지도 않았다면 완벽한 reset입니다.

만약 위와 같이 이미 인덱싱했고 commit까지 했다고 가정하면 

"git fetch origin" 명령어를 치고,

"git reset --hard orgin/master" 명령어로 리셋을 합니다. 그렇다면

결과를 보듯이 commit된 것이 없어졌습니다.

그렇다면 여기서

Pull & Fetch의 차이점이란 무엇인가?

Fetch : 중앙 저장소의 소스를 로컬 저장소로 가져온다!  그러나 현재 작업중인 소스들을 변경하는 Merge 작업을 하지는 않는다

즉, 변경된 소스는 버려지고 원격저장소의 소스로 업데이트가 된다.

Pull : 중앙 저장소의 소스를 로컬 저장소로 가져온다! 또한 현재 작업중인 소스들의 Merge 작업까지 통합하여 수행한다

변경된 소스 + 원격저장소 소스가 merge된다.

GitHub - 간단한 Git사용법(로컬 레포지토리,원격 레포지토리)

Git이란?

-깃(git)은 프로그램 등의 소스 코드 관리를 위한 분산 버전 관리 시스템입니다. 깃의 작업 폴더는 모두 기록하고 있어서 추적이 가능하고, 완전한 형태의 저장소입니다. 

Github란?

-git을 호스팅해주는 웹 서비스이며,  git 저장소 서버를 대신 유지 및 관리해주는 서비스입니다. 

오픈소스 프로젝트는 무료이며, private 프로젝트는 유료입니다. 다른 유저들과 함께 온라인으로 하나의 프로그램을 제작하는 것도 가능하여, 많은 오픈소스 프로그램들이 github을 통해서 전세계 유저들에 의해 제작되고 있습니다. 

Github를 왜 사용하는가?

▶︎▶︎▶︎깃허브 회원가입하기

위의 링크를 타고 들어가서 깃허브에 로그인 혹은 회원가입을 해줍니다.

가입 이후 원격 레포지토리를 생성해준다(Create New Repository)

윈도우에선 방금 설치한 Git Bash 앱으로, OS X에선 터미널로 시작한다. 

git의 기본정보를 입력해준다. user.name = "your name", user.email = "your email"

git config --list 명령을 통해 입력한 정보가 출력되는 것을 확인 할 수 있다.

다음은 로컬 레포지토리를 만든다.(원격 레포지토리와 연결될 본인 PC의 로컬 레포지토리)

로컬 레포지토리로 사용할 디렉토리를 생성해준다.

생성한 디렉토리에 git의 로컬 레포지토리로 사용하는 디렉토리라고 명령을 내려주는 것이다.

Readme.txt라는 파일을 하나 만들어준다. 그리고 해당 파일의 내용을 원하는데로 수정해준 후에

git status라는 명령으로 로컬 레포지토리의 상태를 확인한다.

"On branch master"란 아직 branch를 생성 혹은 branch off 하지 않았기 때문에

현재는 master branch상에 상주하고 있다는 뜻이다.

그리고 방금 생성한 Readme.txt가 git의 관리하에 존재하지 않는 다는 뜻으로 Untracked files 목록에 뜬다.

"git add Readme.txt"라는 명령으로 이제는 Readme.txt가 git의 관리하에 있는 파일로 되었다. 

그리고 "git commit -m "Add Readme.txt" 명령을 통해 지금까지의 변경사항을

commit 하고, commit message로 "Add Readme.txt"를 남겼다.

커밋 메시지는 현재형으로 작성하는 것이 좋다. 버전 관리는 현재 시점의 변경사항을

반영하는 것이기 때문에 항상 현재형으로 작성하는 것이 사상에 맞는 것 같다.

이제 "git status" 명령어를 치면 Readme.txt가 잘 추가 되어있을 것이다.(new File)

다음은 Remote Repository와 Local Repository를 연결할 것이다.

해당 명령으로 원격 레포지토리에 대한 정보를 입력해줄 수 있다.

"https://github.com/yourname/yourrepositoryname.git"

반드시 url에 ".git"을 붙여주어야한다.

혹시라도 나처럼 .git 안붙이고 잘못 연결한 사람이 있을 것같아서 orgin을 삭제하는 명령어를

예제로 해보았다.

"git remote rm origin"을 통해 현재 연결된 origin을 제거한다.

원격 레포지토리와 로컬 레포지토리가 잘 연결된 것을 볼 수 있다.

다음은 변경사항을 커밋했으니 원격 레포지토리에 push 할 차례이다.

위의 명령어로 원격 레포지토리에 변경사항을 merge할 수 있다.

혹시나 아래와 같은 메시지가 뜬다면 해당 레포지토리의 브랜치가 존재하지 않는 다는 뜻이다.(ex- git push origin branch-1, master branch는 기본으로 생성되는 브랜치이다.)

fatal: The current branch master has no upstream branch.

To push the current branch and set the remote as upstream, use

    git push --set-upstream origin master

"git push -u origin master" 명령을 통해 master branch가 없으면 생성하여 push하라는 명령어를 날려준다.

만약 이미 만들어 놓은 원격 레포지토리가 있고, 그곳에 소스들이 존재한다면 원격 레포지토리를

clone하여서 로컬 레포지토리에 동기화(내려받는다)를 한다.

아까 입력한 메시지와 파일 그리고 파일 내용으로 push가 된것을 확인할 수 있다.

Git의 주요 명령어

깃은 리눅스와 같은 큰 프로젝트를 염두에 두고 디자인되었기 때문에, 깃 명령어는 아주 많다. 그러나, 깃의 기본을 사용할 때에는 몇 개의 명령어만 알면된다. 모두 “git”이란 단어로 시작된다.