첫 팀프로젝트다 보니 서투른 점들이 많았습니다.
적용한 이유
여러명이 작업을 하고 gitflow 전략을 팀원들의 수준에 맞게 적용하기 위해서
Workflow를 만들어 CI 를 자동화 해야 할 필요성을 느꼈습니다.
- 각 서비스의 필요한 값들이 서로 설정하는것이 달랐고 코드가 적을땐 바로바로 식별이 가능했지만 코드양이 많아지며 문제점을 식별하는데 시간이 오래걸림
- 서로의 테스트를 만들어놓고 테스트를 통과해야 merge를 할 수있도록 설정
- DB를 사용할때 좀더 편리하게 관리를 할 수있도록 RDS를 도입
1. GitHub Actions vs Jenkins
CI/CD 자동화를 위해 대표적으로 두가지가 있다 Github Action과 Jenkins가 있습니다. 따라서 이두가지를 비교해보고 어떤것을 사용할지 생각해봅시다.
먼저 각 툴의 장점만 알아보면
Jenkins
- 프로젝트의 표준 컴파일 환경에서 컴파일 오류 검출
- 자동화 테스트 수행
- 코딩 규약 준수여부 체크
- 프로파일링을 통해 소스 변경에 따른 성능의 변화 감시
- 테스트 환경에 대한 배포작업
- 개발 업무를 도와주는 많은 플러그인을 가지고 있음
GitHub Action
- 기존의 Circle CI / Travis CI / Jenkins CI와 같은 서비스 또는 설치형 CI처럼 Github에서도 Actions이라는 CI툴을 선보였으며 별다른 복잡한 절차 없이 Github를 통해 사용할 수 있다는 장점이 있다.
- 워크 플로우 복제 용이
- GitHub와 통합
- 라이브 로그
- 다중 컨테이너 테스트
- 리눅스, 맥, 윈도우, ARM 및 컨테이너를 쉽게 빌드, 테스트
- 여러 운영체제 및 런타임 버전에서 동시 테스트 가능
- 모든 언어 어플리케이션 빌드, 테스트 및 배포
🤔 제가 느끼기엔 크게 차이점을 느끼지 못했습니다. 이외에도 Jenkins는 Private 환경에서도 할 수있다는것, 스케줄링 기능을 지원한다는것 등 더 있습니다. 하지만 우리는 프로젝트내부에서 스케줄링기능을 사용 하고 있으며 MSA 환경으로 사용할 겁니다. 하나의 서비스가 문제가 되더라도 간편하게 CI/CD를 할 수만 있다면 상관없다고 생각하였고 사용하기 좀더 편리하고, 특히 이번 프로젝트에선 Git,GitHub를 사용하고 Public 으로 설정할거기때문에 GitHub Action 을 사용하기로 판단하였습니다.
진행하며 수정이 필요 했던것들
1.mysql, mariadb 통일이 되지않음 그래서 yml, gradle 과같은 파일들을 ignore 처리하여 업로드 하지않았습니다.
-
문제점: 로컬에서는 본인의 환경에맞게 실행하지만 github action을 도입했을때
yml, gradle 파일이 없어서 build 가 되지않았습니다. -
해결방안: AWS RDS 를 사용하여 팀프로젝트의 db를 통합
2.AWS RDS 를사용하니 문제점이 있었습니다. yml, gradle 파일을 올리기위해 적용한거지만 rds의 end-point, username, password 등이 노출이 되지않게 해야합니다.
-
문제점: yml 의 내용을 어떻게 해야 안보이게 할까?
-
해결방안: Jasypt 를 사용하여 암호화를 하였습니다.
3.Jasypt 를 사용하니 github action 에서 암호화키가 없어 암호화가 되지 않는 문제가 있었고 여러가지 문제가 있었습니다.
-
문제점: github action 에서 암호화키가 없어 복호화가 되지않음.
-
해결방안: github repository secret에 환경변수를 넣어서 해결
4.github action까지 ci/cd 자동화를 구축하고 로컬에서도 정상적으로 작동하게 됐습니다. RDS 의 부담을 덜어주기위해 배포환경, 개발환경을 분리하는 작업이 필요했습니다.
profile 로 테스트를 명시해주는 방법, class 의 위에 @TestPropertySource(properties = { "spring.config.location=classpath:application-test.yml" })
와 같은 어노테이션을 달아서 경로를 설정 해봤으나 경로 설정으로 인해 github action이 찾을 수 없었음
-
문제점: application 실행, 테스트시 속도가 너무 느리다는 단점이 있었고 로컬환경과 분리의 필요성을 느낌
-
해결방안: applicaton.yml 과 application.properties를 두개를 운용해서 yml은 테스트용 properties는 배포 환경에서 사용하도록 하였습니다.
https://github.com/PARKPARKWOO/githubActionTest
회고
아마 더 좋은 방안이 생긴다면 변경될 수 있겠지만 현재는 로컬에선 vm option을통해 복호화실시 , github 에서는 환경변수로 복호화 하고 test 속도를 향상시키기 위해 yml, properties를 구분하여 테스트와 배포환경을 구분하였습니다.(배포환경에서는 테스트를 할 필요가 없다고 생각했기때문)
