인공지능 웹서비스 팀프로젝트 셋째 주 회고 : Gitlab CI/CD

Ji_min·2021년 6월 9일

프로젝트 회고

목록 보기

2/2

1. 뭘 해볼까?

우리 팀은 현재 agile 방법론을 적용해 sprint 단위로 목표를 설정해 작업을 하고 있다. agile 방법론의 지향점이 최대한 빠르게 서비스를 만들어 출시한 후 사용자들의 반응을 보면서 서비스를 개선해나가는 것이라는 점을 고려한 우리의 목표는 우선 이번 주까지 목표한 기본 기능 구현을 끝내고 서비스의 큰 틀을 완성하는 것이었다.

여기서 문제 아닌 문제가 생겼다. 다들 개발에 있어 각자의 속도가 있기 마련인데, 나는 내가 맡은 기능 개발을 생각보다 일찍 끝내게 되었다. 테스트 코드를 짜면서 개발해서인지 예상했던 것보다 코드 짜기가 훨씬 수월했다. 그래서 팀원들에게 내가 분담할 수 있을 만한 일을 물어봤는데, 애초에 기본적인 기능에 대한 구현만을 목표로 삼았기 때문에 다들 딱히 자기 일을 타인에게 맡길 만큼 타이트한 상황이 아니었다. 그렇다면 추가 기능을 먼저 개발하고 있으면 어떨까 하는 의견도 이야기해봤는데, 아무래도 아직 기본 기능 구현을 완전히 끝내지 않은 상황에서 추가 기능을 논의하기는 부담스러운 것 같았다.

그래서 잠시 주어진 여유로운 시간 동안 뭘 더 해볼 수 있을까 고민해보다가, CI/CD 파이프라인 구축을 통해 테스트 자동화 개발 환경 만들어보자, 고 마음먹었다.

2. CI/CD가 왜 필요해?

사실 테스트 자동화 개발 환경을 구축해보자고 생각한 것은 이전부터 한 번 해보고 싶다고 생각한 게 크다. 하지만 개인 프로젝트라면 모를까, 팀프로젝트에서 개인이 해보고 싶으니까 하자, 라는 이유는 새로운 기술을 도입하는 데에 충분한 이유가 될 수 없다고 생각한다. 새로운 시도에는 적응하는 데 드는 비용이 따르기 마련이고, 그러므로 명확한 니즈가 없다면 새로운 시도는 하지 않는 게 더 낫다.

그래서 CI/CD 도구가 왜 필요한지부터 알아보았다. 일단 공부해보고 필요하면 도입해보고, 필요 없다고 판단되면 버릴 생각이었다.

아래 정리한 내용은 다음의 강의를 참고했다.

CI/CD의 개념

CI(Continuous Integration) : 지속적인 통합
- 무엇이 통합의 대상인가? ➡ 코드
- 여러 개발자들의 코드 베이스(소스 코드)를 계속해서 통합하는 것
CD(Continuous Delivery) : 지속적인 배달
- 무엇을 배달하는가? ➡ 서비스

왜 필요한가?

빠르게 개발하려고
Merge Hell을 방지하기 위해
개발자의 멘탈 복지를 위해
다른 부수적인 부분에 신경쓰지 않고 코드만 짤 수 있는 환경을 만들기 위해
플로우 : 코드 작성 → 빌드 → 테스트 → 배포 ➡ 여기서 개발자의 역할은 코드 작성에서 끝나고, 나머지 일을 CI/CD 도구들에게 맡기는 것

결론

CI/CD 파이프라인은 여러 stages로 구성된다. stage에는 lint, test, build, deploy와 같은 단계들이 포함될 수 있다.
현재 우리 팀의 서비스는 아직 배포하지 않은 단계이지만, lint와 test의 경우 커밋할 때마다 자동으로 검사해준다면 편리할 것 같았다. 특히 백엔드의 경우 lint 컨벤션이 명확히 합의되어 있지 않아 그때 그때 코멘트를 남기기 번거로웠고, 테스트 자동화 파이프라인 구축을 계기로 테스트 코드를 작성하며 개발하는 팀 환경이 갖추어지기를 기대해볼 수 있을 것 같았다.
결론 : 한 번 도입해보자!

3. 어떤 도구를 사용할까?

다음으로 고민한 점은 어떤 도구를 사용할지였다. Jenkins를 써보고 싶기는 한데, 아직 배포도 하지 않은 상황에서 lint와 test만을 해볼 수준에는 너무 과한 툴을 다는 게 아닐까? 하는 생각이 들었다. 또 지금 사용하는 깃랩에도 Github Actions처럼 CI/CD를 지원해주는 Gitlab CI/CD가 있었는데, 얘를 사용해봐도 좋을 것 같다는 생각이 들었다. 그래서 Jenkins와 Gitlab CI/CD를 비교해놓은 글을 찾아 읽어보았고, 결론적으로 따로 설치할 필요가 없고 CI/CD performance에 대한 분석을 제공하는 Gitlab CI/CD를 우선적으로 사용해보기로 했다.

Gitlab CI/CD 사용하기

정말 쉽다!!

루트 디렉토리에 .gitlab-ci.yml 파일을 만들어주면 끝이다.

.gitlab-ci.yml 파일을 작성하는 방법도 어렵지 않다.

stage와 job이라는 두 개념을 이해하면 된다.

stage란 build, test 처럼 파이프라인이 수행할 단계를 정의해주는 것이고, job은 각각의 stage가 구체적으로 어떤 내용을 실행할 것인지가 정의된 부분이라고 할 수 있다.

내가 작성한 내용은 다음과 같다.

우선 stage를 정의해 준다.

# lint와 test를 정의
stages:
  - lint
  - test

그 다음 job을 정의해준다. lint와 test 각각의 단계에 있어서 frontend와 backend로 job을 정의해 주었고, 그래서 총 4개의 job이 만들어졌다.
```
lint-backend:
  stage: lint
  image: python:latest
  script:
    - autopep8 -i closet/*.py mypage/*.py recommend/*.py

test-backend:
  stage: test
  image: python:latest
  services:
    - postgres:10.11
  variables:
    DATABASE_URL: "postgresql://postgres:postgres@postgres:5432/ci"
  script:
    - python manage.py test
```
- stage : 어떤 stage인지 명시.
- image : 어떤 도커 이미지를 사용할 것인지. 도커 컨테이너 기반으로 job이 실행되기 때문.
- script : job의 세부 내용을 정의.
- 그 외의 부분들은 해당 job이 의존하고 있는 db나 환경변수 관련 부분이다.

딱 봐도 쉽게 이해가 될 것이다. 매우 간단하다!

이렇게 파일을 만들어주면, 그 이후부터는 깃랩이 파일을 인식하고 CI/CD 파이프라인이 돌아가기 시작한다. 과정과 결과는 왼쪽 사이드바의 CI/CD 탭에서 확인할 수 있다.

그리고 마찬가지로 왼쪽 사이드바의 Analytics → CI/CD 탭으로 들어가면 전체 파이프라인에 대한 분석 리포트를 제공한다.

또, 파이프라인의 결과를 이메일로 알려준다.