담타 프로젝트 관리하기 3-1 - CI/CD 알아보기

들어가며

담타 프로젝트 관리하기 2-1 - Github으로 이슈 관리

담타 프로젝트 관리하기 2-1 - Github으로 이슈 관리

2022년 10월 7일 처음 작성된 Github으로 이슈관리하기..

약 7개월만에 다음 단계를 쓴다.

 

1편에서 Github flow 를 이용하여 브랜치 관리를 해주었고

2편에서 Github issue를 이용해 앞으로 해야할 일, 진행 중인 일들을 issue 기반으로 관리할 수 있게 되었다.

이 과정에서 커밋 컨벤션, 브랜치 컨벤션을 설정해주고 그것을 잘 지켜내가고 있다.

2-2 편에서는 Jira를 이용해보고 Github issue와 비교해보려 했으나, Jira를 약간 사용해본 결과 내 프로젝트의 크기나 업데이트 빈도, issue 등을 고려해봤을 때 굳이 Jira를 쓸 필요는 없다고 생각했다.

그래서 나온 다음 단계인 3편, CI/CD 구축이다.

 

우리가 회사를 다니고, 회사의 프로젝트를 진행한다면 자동화가 안되어 있어도 무조건 해야한다.

그것이 '일'이니까..

개인 프로젝트는 다르다.

내가 과거 Gastby 블로그를 쓰다가 Tistory로 옮긴 이유인데

개인적으로 하는 것은 하다가 귀찮으면 안한다...

그래서 이런 자동화 작업들을 해놔야 생산성이 향상됨과 동시에, 프로젝트도 계속 유지할 수 있다..

 

그리고 개발하는 시간보다 빌드 + 배포의 시간이 오래걸린다면 당연히 작은 업데이트를 자주하게 되기 힘들고 이는 곧 사용자들의 요구사항을 빠르게 수정할 수 없게 된다.

또한 CI를 코드를 통합하고 단순 빌드해주는 것 보다는 이 과정에서 자동화된 테스트를 통해 안전하고 효과적으로 코드를 통합하는 것이 효율적이기 때문에 결국 테스트 코드를 짜게 된다.

근데 또 코드를 다 짜고 테스트 코드를 짠다? 이것도 불편하므로 TDD가 많이 쓰이는 것 같다.

 

즉, 애자일, CI/CD, TDD 이 세 개는 거의 세트느낌이 아닐까..

 

우선 이 글에서는 CI / CD를 구축해보고, 테스트 관련 이야기는 4편에서 다룰 예정이다.

마침 새로운 기능을 개발하였고 바로 적용해보도록 하겠다.

 

CI/CD 란?

CI - Continuous Integration 

지속적 통합, 말 그대로 지속적으로 통합하는 것이다.

지속적으로 통합한다는 것은 결국 빌드와 테스트를 자동화해주는 것이다.

이게 왜 필요하냐면, 하나의 기능 단위로 통합을 하면 통합 과정에서 문제를 겪기 때문에 자주 코드를 통합하라고 자동화를 시켜주는 것이다.

하루 최소 한 번 통합하는 것을 권장하고 있다.

자주 하려면 역시 자동화가 필요하다. 

그래서 결국 빌드와 테스트를 자동화해주는 것이 CI의 핵심이라고 볼 수 있다.

 

1. Github(버전 관리 시스템)에 코드를 푸시한다.

2. 빌드한다.

3. 빌드가 된다면 테스트를 한다.

4. 테스트 결과를 개발자에서 알려주고 문제가 있다면 개발자는 수정하고 다시 푸시한다.

5. 잘 되었다면 배포 가능한 결과물을 만들어준다.

이런 느낌..

 

CD - Continuous Delivery 혹은  Continuous Deployment

지속적 전달 혹은 지속적 배포이다.

CD는 배포를 자동화해주는 건데 Delivery 와 Deployment 두 가지 다 쓰이는 용어이나 약간의 차이가 있다.

Deployment는 프로덕션 환경까지 즉, 정말 앱스토어와 플레이스토어에 배포하는 것 까지 자동화하는 것이고

Delivery는 스테이징 환경까지 자동화하고 그 후 수동적으로 프로덕션에 올리는 것이다.

끝까지 자동화하는 Continuous Deployment가 무조건 좋을 것 같지만 꼭 그런 것은 아니라고 한다.

하나 예를 들면, 배포 준비가 됐지만 최적의 출시 시간 등의 이유로 배포 타이밍을 사용자가 정해야 할 수도 있기 때문이다.

 

AWS 홈페이지에서 가져온 아래의 그림을 보면 CI / CD를 이해하는데 도움이 된다.

출처 : https://aws.amazon.com/ko/devops/continuous-integration/

 

어떻게 할까?

이제 뭔지 알았으니 다양한 자료를 찾아보자.

1. 플러터 공식 홈페이지 - https://docs.flutter.dev/deployment/cd   

2. [Youtube] Flutter Festival Korea - 지식인 앱 CI & CD 소개 - 데비트 https://www.youtube.com/watch?v=XE7arhC6tsc

3. 하루에도 10번 배포하는 Flutter 앱 CI/CD 구축하기 - https://shorturl.at/NPRX1

 

세 가지 자료에서 많은 정보를 얻을 수 있었다.

공식 Docs 에서 설명하는 것은 두 가지가 있다.

All-in-one options / Integrating fastlane with existing workflows

 

All-in-one options

- Codemagic

- Bitrise

- Appcircle

올인원 옵션은 유료이다. 돈 받고 CI/CD 환경을 구축해주는 것이다.

하지만 500분의 빌드타임을 무료로 제공해주기 때문에 나의 경우 굉장히 유용하게 사용할 수 있다.

또한 구축 시간도 적게 든다.

 

Integrating fastlane with existing workflows

Github actions, Travis 등과 fastlane 을 이용해서 하는 것이다.

아무래도 직접 해보기 전에는 나의 이해가 완벽하지 않으므로 ChatGPT 에게 물어보았다.

이렇게 개발자가 코드를 푸시 혹은 PR을 올렸을 때 Github actions 이 그에 맞게 fastlane 을 실행시켜 빌드, 테스트, 배포를 한다고 한다.

Github actions 를 이용해서 빌드를 한다는 것은 컴퓨터가 필요하다는 것인데... 

그 컴퓨터는 어디서 나냐.. 이것은 유료로 써야 한다 ㅎㅎ

물론 Self-hosted runner를 이용해서 무료로 쓸 수도 있지만 대신 내가 갖고 있는 컴퓨터를 이용해서 작업하는 것이다.

 

다음 글

다음 글에서는 우선 환경 구축 속도에 초점을 맞춰 제일 빠르게 구축할 수 있는 올인원 옵션 중 하나를 비교하고 선택해서 환경을 구축해보며 배우고 부족한 점이 있는지 알아갈 예정이다.