github.com과 사내 GitHub를 동시에 사용하고 있을 경우추가버튼을 눌러고 각각의 접근 정보를 추가하면 됩니다
Jenkins Job 생성 [Look]
새로운 Job을 하나 생성하고 구성을 시작
General의 GitHub project에 GitHub 저장소 페이지 주소
소스 코드 관리의 Git에 체크
Repository URL은 저장소의 git 주소
Credentials에 아까 생성한 권한으로 선택
고급을 누른 후 Refspec에+refs/pull/*:refs/remotes/origin/pr/*입력
Branch Specifier에${sha1}입력
빌드 유발의 GitHub Pull Request Builder 체크
GitHub API credentials에 아까 생성한 credentails 선택
Admin list에 저장소 멤버 중 관리자로 지정할 아이디를 한줄 씩 작성
여기 작성한 아이디가 테스트 결과, 댓글 등을 입력한 것과 같이 동작
Use github hooks for build triggering에 체크
GitHub 쪽 변경사항을 polling 뿐 아니라 hook을 통해서 받을 수 있도록 하는 설정이며 좀더 빠르게 반응하도록 합니다
github.com<-> 사내 jenkins 조합의 경우 github.com에서 내부 jenkins에 hook을 발송할 수 없기 때문에 polling으로만 구성해야 합니다
Crontab line을 변경하여 polling 스케쥴 설정 가능합니다
Build에 test를 위한 빌드 세팅을 하고 구성 저장
jenkins에서 구성을 저장하면 GitHub 저장소의 Settings - Webhooks에 자동으로 훅 설정이 됨
GHPRB 플러그인의 hook 주소는http://젠킨스 주소/ghprbhook/
PR 생성 [Look]
전달 받은 int 두개를 더하는 메소드를 일부러 고장내는 PR를 생성
PR 생성 후 얼마 지나지 않아 check가 있다고 표시 됨
일부러 테스트를 통과할 수 없게 만들었기 때문에 check가 실패
GHPRB 자세한 설정 [Look]
GitHub Pull Request Builder는 기본적으로
저장소 관리자가 PR를 생성한 경우: 자동으로 빌드
그외 사용자가 PR을 생성한 경우: 관리자의 승인이 있으면 빌드
관리자가 아닌 사용자가 PR를 생성했을 때 GHPRB 플러그인은 관리자의 승인을 묻는 댓글을 생성
관리자 중 한명이ok to test라고 댓글을 남기면 빌드
모든 PR을 자동으로 빌드하려면
Build every pull request automatically without asking (Dangerous!).에 체크
PR에 새로운 커밋이 올라오면 무조건 자동으로 빌드
모든 PR을 자동으로 빌드하지 않으려면
Only use trigger phrase for build triggering에 체크
Trigger phrase에 빌드 유발 텍스트 설정
GitHub Protected branches [Look]
특정 브랜치에 강제 push/삭제 차단, 머지 전 check 통과 등을 강제할 수 있는 기능
GitHub 저장소 페이지 - Settings - Branches
Protected branches에서 보호할 브랜치 선택
Protect this branch
보호 기능을 활성화
Require pull request reviews before merging
머지 전 PR에 대한 승인이 필요
Dismiss stale pull request approvals when new commits are pushed
승인 후 새로운 커밋이 추가되었을 경우 이전 승인을 무시
Require review from Code Owners
지정된 코드 오너의 승인이 필요
Require status checks to pass before merging
머지 전 체크 통과가 필요
require branches to be up to date before merging
PR 테스트가 반드시 보호된 브랜치의 최신 상태를 포함하고 있어야 함
Status checks found in the last week for this repository
지난 일주일간 이 저장소의 check를 찾아 표시
체크하면 반드시 해당 check를 통과해야 함
Include administrators
저장소 관리자까지 포함
CODEOWNERS 파일
gitignore의 패턴 규칙과 동일
개인은 물론 팀도 지정 가능
# 이것은 주석입니다. # 각 줄에 파일 패턴과 오너를 하나 이상 적습니다. # 이 오너들은 저장소의 모든 파일에 대한 기본 오너입니다. # 나중에 적힌 것들이 매칭되지 않는 한 @global-owner1과 @global-owner2는 # 누군가 PR을 열었을 때 리뷰 요청을 받게 됩니다. * @global-owner1 @global-owner2 # 순서가 중요합니다. 나중에 매칭된 것이 가장 우선순위가 높습니다. # 누군가 JS 파일만 변경한 PR을 오픈할 경우 글로벌 오너가 아닌 @js-owner만 리뷰를 요청 받게 됩니다. *.js @js-owner # 만약 원한다면 이메일 주소를 사용할 수도 있습니다. github 사용자 계정에 등록된 이메일이어야 합니다. docs/* docs@example.com
Review required
이 PR이 승인 되지 않았아 머지가 불가능
All checks have failed
이 PR의 테스트가 실패하여 머지가 불가능
This branch is out-of-date with the base branch
base 브랜치의 최신 내용이 반영되어 있지 않기 때문에 머지가 불가능
Comment
승인은 하지 않고 의견을 남김
Approve
승인을 하며 의견을 남김
Request changes
반드시 의견에 대하여 변경을 해야 함
여러가지 Git workflow 들
Gitflow [Look]
메인 브랜치
항상 존재하는 브랜치
master
배포된 소스가 있는 브랜치
develop
다음 배포를 위한 소스가 있는 브랜치
개발이 완료되면 일련의 과정을 통해 master로 merge
서포팅 브랜치
master와 develop 외에 팀 멤버들이 병렬로 일할 수 있도록 도와주는 브랜치
메인 브랜치와는 다르게 필요할 때마다 생성하였다가 삭제
feature 브랜치
브랜치 생성: develop으로 부터
merge: develop으로
prefix: feature/
feature 브랜치는 특정 기능 하나에 대하여 develop으로부터 생성하여 개발하며 개발이 완료되면 다시 develop 브랜치로 merge
release 브랜치
브랜치 생성: develop으로 부터
merge: master와 develop으로
prefix: release/
release 브랜치는 배포를 위한 준비를 할 수 있는 브랜치
각종 메타 데이터(버전 명 등)를 변경하거나 작은 버그를 수정
배포 준비가 되면 master와 develop에 각각 merge
merge된 master를 배포
release 브랜치를 따로 가져가기 때문에 develop 브랜치에서는 바로 다음 배포를 위한 기능을 시작할 수 있습니다
hotfix 브랜치
브랜치 생성: master로 부터
merge: master와 develop으로
prefix: hotfix/
hotfix 브랜치는 배포된 버전에 긴급한 변경 사항이 있을 때 활용
핫픽스가 완료되면 master와 develop에 각각 merge
merge된 master를 배포
GitHub Flow [Look]
Gitflow는 너무 복잡
대부분의 케이스에서 Gitflow 처럼 복잡한 workflow가 불필요
master 브랜치는 항상 배포 가능한 상태여야 한다
새로운 기능 개발은 명확한 브랜치 이름으로 master에서 생성한다
토픽 브랜치의 커밋은 비번하게 push 한다
피드백, 도움이 필요하거나 merge할 준비가 되었다면 PR을 생성한다
누군가 리뷰를 하고 승인을 했다면 master에 merge한다
master에 merge한 커밋은즉시배포한다
master 브랜치는 항상 배포 가능한 상태여야 한다
GitHub Flow의 유일한 강제 사항
master의 최신 커밋은 최대한 빠르게 배포
배포한 커밋에 문제가 있어 이전 커밋을 되돌려야 하는 케이스는 매우 드물다
문제가 있을 경우 revert 커밋을 하든지 문제를 해결한 후 merge
master 브랜치는 배포하거나 브랜치를 만들기 위해 항상 stable해야 한다
모든 브랜치에 push된 내용은 자동으로 테스트 수행하며 결과를 채팅창으로 받음
명확한 브랜치 이름으로 master에서 생성한다
master에서 명확한 이름으로 브랜치를 만들어 작업을 시작한다
fetch를 통해 나뿐 아니라 다른 사람들의 현재 작업 현황을 파악할 수 있다
당분간 현재 브랜치 작업을 중단하였을 때 다시 돌아왔을 때 이름만 보고 어떤 브랜치였는지 기억해내기 쉽다
GitHub의 브랜치 페이지를 통해 최근 작업 중인 브랜치와 작업 상태를 러프하게 알 수 있다
마치 신규 기능 목록
토픽 브랜치를 지속적으로 push
서버에 꾸준히 push함으로 개인 컴퓨터 문제로 인한 loss 걱정이 없다
fetch / GitHub 브랜치 페이지를 통해 우리의 TODO들을 파악할 수 있다
언제나 PR을 생성
라인 단위로 코멘트 가능
PR 자체에도 코멘트 가능
새로운 커밋을 push하면 반영 됨
이 모든 것이 타임라인으로 표시 됨
PR이 너무 오래 열려 있어 master와 멀어졌다면 master를 merge
리뷰가 완료된 것만 merge
master에 바로 작업하지 않고 토픽 브랜치에서만 작업하며 완료되었다고 생각했을 때 merge
다른 사람에게 승인을 받음.
,
이후에 CI를 통과한 브랜치만 merge
리뷰 후 즉시 배포
master에 merge가 되면 내가 당장 배포하지 않더라도 몇 시간 내에 다른 사람이 merge한 커밋을 기반으로 새로운 작업을 시작하고 배포할 수 있다
다른 사람이 내가 잘못 개발한 내용을 배포하는 것을 원하지 않기 때문에 사람들은 토픽 브랜치가 merge 되었을 때 정말 stable한지 확인하려는 경향이 있다
채팅창을 통해 회사 내 누구나 배포가 가능
hubot depoy github to production
6명의 다른 사람들(디자이너와 서포팅 스텝 포함)이 하루 사이에 24번 배포한 기록
GitLab Flow [Look]
GitHub Flow는 심플하지만 배포, 환경, 릴리즈 등을 해결해주지 못 함
Production branch
GitHub Flow는 master 브랜치의 지속적인 배포를 가정하지만 적합하지 않은 케이스도 존재
예> iOS 앱은 배포 시 심사 과정이 필요, 배포 시간이 제한적일 때(운영 팀이 10am ~ 4pm까지 일할 때)
배포가 필요할 때 master에서 production으로 merge를 하여 배포
production에 hotfix가 필요할 경우 production에서 패치하는 것이 아니라 master에서 패치 후 master 검증 후 production에 cherrypick
production에서만 패치 후 패치 결과가 master에는 잊어버리고 반영되지 않는 문제를 해결하기 위해
Environment branches
production 단계 전 pre-production 환경이 존재한다면 pre-production 배포를 위해 master에서 pre-production으로 merge
리얼 배포를 위해서는 pre-production에서 production으로 merge
Release branches
마이너 버전 릴리즈 브랜치가 존재
릴리즈 브랜치는 stable한 master에서 시작
릴리즈 브랜치를 생성하는 때는 최대한 늦게 가져가 각각의 브랜치에 버그를 픽스 해야 하는 상황을 최소화
릴리즈가 공개된 후에는 치명적인 버그만 픽스
가능하다면 버그 픽스는 master에서 진행 후 각 브랜치로 cherry-pick
master에 반영하는 것을 잊어 이후 릴리즈에서 버그가 다시 나타나는 것을 방지
패치 버전은 새 태그를 사용하여 표시
NHN Edu 서버개발팀은? [Look]
단기간의 배포 일정
6/28, 7/18, 7/26
장기간의 배포 일정
코드 네임을 부여
strewberry, tomato
같은 시간에 여러 배포 일정의 작업이 필요
Gitflow 기반으로 develop 역할의 브랜치를 여러개 사용
rebase 적극 활용
모든 배포 일정 브랜치는 develop에서 시작
각 브랜치 내에서 feature 브랜치 생성, merge
PR를 통해 자동 테스트
merge 전 rebase를 이용
다가오는 배포 일정의 개발이 완료되면 해당 브랜치를 이용하여 QA 진행
QA 완료 후 master와 develop에 merge
남은 배포 일정 브랜치들을 develop에 rebase (이때-p옵션을 이용하여 머지 커밋을 유지)
각자의 feature 브랜치를 각 배포 일정 브랜치에 rebase
이 때 rebase 중 충돌이 많이 발생하면 cherry-pick
hotfix가 필요할 경우 hotfix 브랜치 생성 후 master와 develop에 merge
댓글