일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 지연로딩
- nonclustered index
- ci/cd
- GithubActions
- 동시성
- 재고 시스템
- 부하테스트
- JAVA8
- B+TREE
- lazyloading
- 주문
- Redis
- Jenkins
- 공변
- JPA
- backend
- 웹캐시
- CaffeineCache
- 제네릭
- Ehcache
- method area
- Spring Data Redis
- 리팩터링
- JDK14
- Metaspace
- java
- 상태패턴
- 트랜잭션
- springboot
- 카카오 화재
- Today
- Total
NDM
2. GithubActions를 이용한 CI/CD 구축 일지 1편 본문
배달 플랫폼 API 서버 프로젝트를 진행중입니다.
매번 빌드하고 서버에 배포하는 과정을 자동화하고 시간을 단축하기 위해 CI/CD를 구현했습니다
왜 자동화를 선택했는가
두 가지 관점에서 바라보겠습니다
첫 번째는 이것을 수동으로 진행한다면, 합쳤을 때 꽤 많은 시간이 소요된다는 것입니다
프로젝트 빌드 -> 테스트 -> 패키징 압축 -> 배포 .. 하는 과정을 일일히 수동으로 한다고 생각해 보세요
귀찮은 것도 귀찮은 것이지만, 프로젝트의 크기가 커질수록 시간은 비례해서 늘어나게 됩니다
사실 제 프로젝트같이 실 서비스가 아닌 토이프로젝트에서는 이러한 첫번째 이유가 주된 이유일 것입니다
두 번째는 협업을 하는 경우에, 내가 아닌 테스터나 기획쪽 팀원이 개발 반영 사항을 확인할 수 있다는 것입니다
쉬운 이해를 위해 예를 들어보겠습니다.
개발자의 개발환경인 로컬, 개발 결과를 테스트하는 환경인 개발계, 실제 사용자가 사용하는 환경인 운영계
이렇게 세 가지 환경을 구축했고, 함께 협업으로 프로젝트를 진행하는 상황입니다
이 때, 개발자가 아닌 테스터나 기획 즉, 개발자가 아닌 프로젝트 팀원이
개발 반영 사항을 확인하기 위해서 계속해서 개발자에게 메신저를 보내고, 부탁을 해야한다면 어떨까요??
운영계와 달리 개발계는 자유롭게 배포하는 상황이 많고, 데이터도 임의대로 수정가능한 환경이기 때문에
변경이 매우 잦습니다. 이 때마다 계속해서 개발자에게 메신저를 보내고, 부탁을 해야한다면 어떨까요??
밀려드는 일도 정신 없는데 배포만 해야하는 상황이 생길수도 있습니다. 굉장히 비효율적이겠죠
자동화 툴을 알아보자
CI/CD 툴에는 GithubActions나 TravisCI, CIrcleCI 등 많은 소프트웨어가 있지만 가장 압도적인건 단연 Jenkins입니다
Jenkins는 Java로 제작된 오픈소스 CI(Continuous Integration) 툴이다.
SonarQube 등의 코드 품질관리 플랫폼과 셸 스크립트, 윈도우 배치 프로그래밍, Ant/Maven/Gradle 기반 프로그램을 지원한다.
Jenkins 2.0부터 많은 보안 옵션이 기본적으로 활성화되어 Jenkins가 관리자가 특정 보호 기능을 명시적으로 비활성화하지 않는 한 환경은 안전하게 유지되고 있다. - 나무위키 -
장점은 다음과 같습니다
- 무료이다
- 지원 플러그인이 매우 많다
- 공식문서 로드맵을 지원하며, 관련문서가 매우 많다
하지만
- 별도의 서버를 구축해야 하며
- 이로인해 서버가 다운되거나 하면 이용할 수 없다
라는 단점도 있습니다
그리고 요즘 GithubActions가 많이 떠오르고 있습니다
장점은 다음과 같습니다
- 굉장히 쉽습니다
- Github를 통해 실행하므로 별도의 서버를 구축할 필요도 없습니다
- Github에서 MarketPlace를 제공해 잘 짜여진 파이프라인을 확인할 수 있으며, 공식문서도 꽤 잘 되어있습니다
- Github에 접근할 때 별도의 설정을 해 줄 필요도 없습니다
하지만
- 이름에도 써있는 만큼 Github에 매우 의존적이고
- private repository를 사용할 경우 유료입니다
- 회사에서 Github외의 형상관리 툴을 사용한다면(SVN같은) 굳이 사용할 필요가 없습니다
나는 왜 GithubActions를 선택했는가
저는 취준생이고, 토이프로젝트를 진행중입니다. 그리고 Github를 형상관리 툴로 사용합니다
Jenkins의 장점을 인용해 GithubActions를 사용한 이유를 말씀드리겠습니다
Jenkins의 장점은 다음과 같았습니다
1. 무료이다
- GithubActions도 public Repository를 사용한다면 무료입니다.
- 또한 저는 private Repository를 사용중이지만
대학생 혜택으로 pro 계정이기 때문에 한달에 1GB, 3000분까지 무료 혜택을 누릴 수 있습니다
2. 지원 플러그인이 매우 많다
- GithubActions가 지원하는 기능은 Jenkins보다는 확실히 적습니다.
하지만 저는 그 많은 플러그인의 기능을 사용하지 않습니다 - jdk 세팅 -> 빌드 -> 테스트 -> 도커 이미지 푸시 -> 배포의 과정으로 파이프라인이 이루어져 있는데,
이러한 기본적인 기능은 대부분의 CI/CD 툴에서 지원하는 기능입니다 - 현업이라면 제가 모르는 어떤 플러그인을 사용할 수도 있겠지만, 당장의 제 프로젝트에서는
GithubActions 만으로도 충분히 구현이 가능했습니다
3. 공식 문서의 로드맵을 지원하며 관련 문서가 매우 많다
- GithubActions또한 마켓플레이스에서 잘 짜여진 파이프라인 파일을 확인할 수 있으며,
최근 사용자가 많아져 구글 서치만으로도 충분히 검색이 가능합니다 - https://github.com/marketplace/actions/slack-notify
- 예를 들어 slack과 연동을 하는 경우, 이러한 마켓플레이스를 보시면 됩니다. 이것 외에도 각 step별로 어떤 설정을 해야하는지, 어떠한 파라미터가 들어가는지 굉장히 설명을 잘 해놔서 Jenkins보단 훨씬 쉬웠습니다
4. 별도의 서버를 구축해야 한다
- 사실 취준생에게는 은근히 이게 신경쓰였습니다. 프리티어를 사용해도 되었지만, 일단은 최대한 리소스를 아끼고 싶었거든요. 이렇게 신경쓰이는 상황에서 GithubActions라는 훌륭한 대안이 있으니 굳이 Jenkins를 사용할 필요가 없었습니다
참고
https://velog.io/@sgwon1996/Jenkins-vs-GitHub-Action-vs-Tekton
https://www.jenkins.io/project/roadmap/
'[프로젝트] Slow Delivery' 카테고리의 다른 글
7. GithubActions를 이용한 CI/CD 구축 일지 2편 (0) | 2022.10.24 |
---|---|
6. 재고 감소 -> 주문이 맞을까, 주문 -> 재고 감소가 맞을까? (0) | 2022.09.14 |
5. 주문 트랜잭션 설계와 Transaction 내부에서의 호출 문제 (0) | 2022.09.14 |
4. 재고 처리 로직 동시성 이슈 해결 일지 (0) | 2022.08.31 |
3. FetchType = Lazy를 명시해도 Lazy Loading이 적용되지 않는다?? (0) | 2022.08.18 |