우리 회사에 왜 CI / CD가 필요한가
먼저 CI/CD란 Continuous Intergration(지속적인 통합)과 Continuous Delivery(지속적인 제공) 혹은 Continuous Deployment(지속적인 배포)의 약자이다.
CI
1. 코드 변경사항을 주기적으로 빈번하게 머지해야한다.
두 개발자가 같은 파일을 오래동안 개발하다가 같이 Merge를 하게 된다면
발생하는 에러와 버그들은 엄청날 것이며 이것을 해결하는 것이 개발하는 것 보다 더 큰일이다.
2. 빌드, 테스트, 머지의 자동화
빌드와 테스트를 자동화하기 때문에 편리하며 빌드 혹은 테스트 시 발생하는 에러를 잡아주어
개발자에게 알려주기 때문에 배포에 있어 안정성이 높아진다.
CD
1. CI 과정이 끝나고 문제가 없다면 Release가 되고 개발자 혹은 담당자가 수동으로 배포한다.
2. Release를 마치고 자동으로 배포를 하는 경우를 Continuous Deploy 라고 부른다.
간단하게 CI/CD의 개념을 알아보았고 왜 우리 회사에 CI/CD가 필요한지 알아보자.
지금의 회사의 빌드 방법은 다음과 같다.
빌드 서버에서 SpringBoot의 jar 파일과 React에서 빌드한 build 폴더를 복사하여
붙여넣고 nginx를 수동으로 실행시켜 배포하고 있다.
매번 복사 붙여넣기하는 우리의 모습이 개발자스럽지 못하고 비효율적이라는 생각을 많이 했다.
이에 우리는 배포할 때마다 빌드한 파일들을 복사하여 붙여넣는 방식을 CI/CD 툴을 사용하여
자동 빌드와 배포 서버에 자동으로 파일을 넘겨주도록 하였다.
다양한 CI / CD 툴
2023년 CI/CD 툴들이 정말 다양하고 많아졌다.
프론트 개발을 하면서 CI/CD를 들어보고 GitHub Actions를 사이드 프로젝트에 도입하는 시도했었다.
위 사진은 JetBrains에서 2023년 CI 툴의 사용 순위를 조사했다.
예상과는 다르게 GitHub Actions가 1위를 차지했고 2위로는 Jenkins가 차지하여였다.
이어 GitLab CI와 Azure DevOps 그리고 Circle CI와 Travis CI가 뒤를 이었다.
당연히 Jenkins가 압도적인 1위를 했을 것이라는 예상과는 다르게
GitHub Actions도 많이 사용하시는걸 알게되었다.
이 중 회사에서 사용할 툴은 바로 Jenkins였다.
첫번째로 회사의 깃허브 계정은 유료가 아니다.
GitHub Actions는 유료 계정이 있어야 원활하게 사용이 가능하다.
무료도 사용이 가능하나 한 달에 배포 제한(시간 제한)이 있기 때문에 감점 요인이 되었다.
두번째로는 Jenkins의 많은 레퍼런스들이다.
Jenkins의 GitHub Actions 보다 레퍼런스들이 GitHub Actions 보다는 많기 때문에 보다 에러 핸들링에 수월할 것이라 판단했다.
========>
라고 생각했지만 위 사진을 보다시피 GitHub Actions를 사용 중인 회사들도 많아졌고
그만큼의 레퍼런스들도 많이 있어서 Jenkins와 크게 다르지 않다고 생각한다.
형상관리 툴로 GitHub를 사용한다면 GitHub Actions이 더 좋지 않을까 싶다.
<========
FreeStyle VS Pipeline
Jenkins에서 CI 프로젝트를 만들 때 두 가지 선택사항이 있다.
바로 FreeStyle과 Pipeline이다.
FreeStyle Project
FreeStyle은 Jenkins에서 기본적으로 빌드에 대한 가이드라인을 제시해주는 프로젝트이다.
형상 관리 툴은 어떠한 것을 쓰는지.
빌드 유발은 어떻게 할 것인지.
빌드 환경은 어떠한지.
빌드는 어떻게 할 것인지.
빌드 후에는 또 다른 조치를 할 것인지.
기본적인 파이프라인을 만들어주고 사용자가 선택하는 방식의 프로젝트이다.
처음 CI/CD를 사용하는 사용자에게 가이드라인을 제시해주므로 편리하며 친절하다.
하지만 커스터마이징이 어려워 복잡한 파이프라인 설계가 어렵다는 점이 단점이다.
Pipeline Project
Pipeline은 배관을 설계하는 것과 같이 CI/CD의 흐름을 사용자가 직접 설계하고 관리한다.
FreeStyle에 비해 커스터마이징이 쉽고 어떠한 구간에서 실패를 하였는지 UI로 확인이 가능하다.
다만 진입장벽이 높고 레퍼런스가 FreeStyle에 비해 적다는 단점이 있다.
이러한 장단점을 비교했을 때 DevOps 파트가 따로 없는 현재로서는 FreeStyle로 진행하는게 맞다 생각을 했다.
"거기 보안 부서죠 ?"
Jenkins는 따로 서버를 만들어 관리를 해야하기 때문에 남는 서버에서 설치를 해야한다.
문제는 방화벽 때문에 설치가 안되는 것이였는데 Jenkins 설치는 보안팀에게 방화벽 해제를 요청하여서
설치를 완료했다.
그럼에도 Build 시 .org(organization) 또한 방화벽에 막히는 일이 자주 있었고
Jenkins Plugin 또한 방화벽 때문에 설치가 안되는 경우가 많았다.
만약 사내 방화벽이 있는 곳에서 CI/CD를 도입을 한다면 자주 에러가 발생할 것이다.
이는 구글링으로도 잘 안나오기 때문에 에러 메시지를 잘 확인하고 해결 해야한다.
FTP ? SFTP ??
빌드까지 완료가 되었다면 이제 배포 서버로 해당 빌드 파일을 넘겨주어야한다.
이때 우리는 Publish Over FTP 또는 Publish Over SSH라는 플러그인을 설치하여
원격으로 파일을 보내주어야한다.
먼저 FTP와 SFTP를 알아야하는데 이는 인터넷을 통해 파일의 송수신을 지원하기 위한 프로토콜이다.
즉 우리가 원격으로 파일을 보내주기 위해 사용되는 프로토콜인 것이다.
FTP
- 평문 통신을 사용하기 때문에 암호화가 되어있지 않아 보안에 취약함.
- 21번 포트를 사용.
- 파일 관리를 위한 명령어 존재.
- FIleZilla나 WinSCP와 같은 클라이언트 프로그램 지원.
SFTP
- SSH 프로토콜을 사용하여 데이터를 암호화하여 보안이 좋음.
- 22번 포트를 사용.
- SSH Shell을 사용함으로 다양한 기능을 제공.
- SSH 클라이언트를 사용하여 접속해야 하므로 사용성이 떨어짐.
따라서 보안이 크게 중요치 않다면 FTP를.
보안이 중요한 파일이라면 SFTP 방식을 채택하는 것이 좋다.
방화벽이 있는 서버이기에 사용성이 좋은 FTP를 사용하기로 하였다.
마무리.
이렇게 FTP를 사용하여 Jenkins 서버에서 배포 서버로 원격 파일 전송까지 마무리되었다.
사수는 백엔드 쪽을 담당하였고 나는 프론트 쪽을 담당하여 두 개의 Item을 만들어 자동 빌드를 완성시켰다.
회사 내부망을 잘 알고 있는 사수님께서 고생을 많이해주셨고
좋은 레퍼런스들과 정보 공유를 적극적으로 해주셔서 프론트도 무사히 마치게 되었다.
추후 nginx를 통해 포트를 나누어 무중단 배포도 도입을 해볼 생각이다.
CI/CD 경험을 요구하는 JD를 많이 적어놓는다.
이로서 CI/CD 경험치도 쌓았다.
다만 아쉬운 점은 JUnit이나 Jest같은 테스트가 없는 프로젝트에 도입한 것과
Pipeline이 아닌 FreeStyle을 사용 했다는 점이다.
그래도 충분히 불편했던 부분을 해소하였고 큰 경험치를 얻어갔기 때문에 보람을 크게 느꼈다.
젠킨스 짱.
