유데미 강의를 들으며 수업 내용을 기록하고 있다.
1. gitlab 접속
지난 시간에 .gitlab.yml skeleton 파일을 작성하였다.
작성후, git push까지 진행했었다.
2. merge request 진행
gitlab-ci-cd-skeleton브랜치에서
master 브랜치로 merge
좌측 CI/CD 메뉴에서
작업(job)이 작동중임을 확인할 수 있다.
왜 job이 작동된걸까?
지난 시간에 정의한 skeleton 파일 때문이다.
master 브랜치에
merge request가 왔을때 트리거가 작동됐다.
중요한 것은
merge 이전의 request가 왔을때 작동됐다는 것이다.
3. gitlab.yml 파일 validate
gitlab은
gitlab.yml 파일 포맷 및 syntax를 validate해주는 기능을 제공한다.
CI Lint
클릭 후 아래와 같은 화면이 나타난다.
이곳에 지난 시간 vscode에서 작성한 파일을 붙여넣기 해보자.
4. merge 진행
이제 merge하자
마지막 stage를 진행하자.
.gitlab.yml에서 destroy stage의 경우
manual로 진행하게 설정해뒀었다.
5. 중간 내용 정리
자,
우리가 하고 있는 것을 메타언어로, 두괄식으로 말해보면
파이프라인을 구축하고 있다.
.gitlab.yml 파일에
여러 stage들을 정의했었다.
각 stage가 6개인지, 7개인지 그 개수가 중요한게 아니다.
rules 가 중요하다.
rules 에 정의한 조건이 만족할때
트리거가 작동되기 때문이다.
우리는 master 브랜치에 merge request가 오거나
master 브랜치에 merge 됐을때
특정 stage가 작동되도록 정의했다.
이번 포스트에서 1 ~ 4번까지는
master 브랜치에 관련된 rules가 포함된
stage들이 작동되는 것을 확인했다.
하지만, ``production``브랜치에 merge request 또는 merge 되는 트리거 또한 정의했지만 아직 진행하지 않았다.
자 그럼 지금 무엇을 해야할까.
gitlab에는 production 브랜치가 없다.
브랜치 먼저 생성하러 가자.
6. production 브랜치 생성
production브랜치를 생성하니
stage들의 job들이 작동되고 있다.
왜 작동되는 걸까?
7. production 브랜치 보호하기
