시작하기 전에
기업체 구인공고들을 보면 DevOps 직무라던가, 서버 엔지니어 직무를 보면 CI/CD를 다룰 줄 알아야한다는 정보가 쓰여있다. 아래는 데브시스터즈 신입채용의 DevOps 직무소개 중 하나 이다.
CI/CD 파이프라인을 구축한다는데 도대체 CI/CD 가 무엇일까? 최근 인포뱅크에서 면접을 봤을 때도 면접관님이 CI/CD를 알고 있냐고 물었는데 답을 못했던 기억이 있다. 그래서 찾아보고 적으려고 한다.
아무래도 글을 쓰다보니 Github를 다루다보니까 Github 위주로 설명을 쓰게 되었다.
CI/CD
Redhat 사이트에선 CI/CD는 애플리케이션 개발 단계를 자동화하여 애플리케이션을 보다 짧은 주기로 고객에게 제공하는 방법이라고 소개한다. 어라? 이거 완전 소프트웨어 공학시간에 배운거 아닌가? 게다가 이번 프로젝트를 진행하면서 Github를 관리하는 도중 분명히 이런 작업을 한거 같은데...
- CI : 지속적인 통합(Continuous Integration)
- CD : 지속적인 서비스 제공(Continuous Delivery) 및/또는 지속적인 배포(Continuous Deployment)
그런데 아무래도 지속적인 통합은 뭐고, 지속적인 서비스 제공이란 말들이 어렵다. 조금 더 자세히 알아보자.
지속적인 통합(CI)
개발자는 각자 맡은 바 일을 하게 된다. 그게 패키지단위가 될 수 있고, 기능단위가 될 수 있다. 중요한 건 그렇게 각자 작업한 코드들을 통합해주는 과정이 필요하다. 이걸 꾸준히 하면 지속적인 통합이다.
만약, 이 정도 패키지를 관리하는 나와 서울수달이라는 팀원이 있다고 하자.
몫을 이렇게 두 개로 나누자고 약속을 할 수 있다. 그래서 둘이 열심히 일하자해서 패키지를 만들어낸다. 근데 이 패키지들을 어떻게 합치지?
완성됐다고 끝이 아니고, 지속적으로 사람마다 수정/삭제가 들어가게 될텐데 이럴때마다 프로젝트를 합치는게 개발자라면 개발자가 개발을 못하는 경험을 할 수 있겠다.
그래서 DevOps라는 직책이 이 지속적인 통합을 맡는다고 생각이 든다. 그럼 개발자들이 코드만 넘겨주면 현 프로젝트 패키지 위치에 맞게 통합해주면 된다.
보통 Github를 사용함으로서 얻는 최대 강점을 물어본다면, 한 프로젝트를 여러명이 동시에 참여할 수 있다는 점을 꼽을 것이다. 근데 그게 왜 장점일까?
이런 상황에서 Pull Request를 하면 CI가 지속적으로 가능하기 때문이다. Github를 사용하면 어느정도 CI가 자동화되어있다고 생각할 수 있겠다.
지속적인 서비스 제공 & 배포(CD)
CD는 위 지속적인 서비스 제공과 배포 둘 다 말한다.
서비스 제공은 말그대로 개발자에 의해 수정되는 코드들이 지속적으로 서비스 상태에 적용될 수 있도록 해주는 것이다. 바뀐 코드는 위에서 말한 CI가 제대로 구성되어 있다면 지속적으로 하나의 프로젝트로 통합될 것이다. 이 때 이 프로젝트를 적용가능한지 확인하려면 빌드는 물론이요 테스팅 자동화가 필요할 것이다. 얼마전 프로젝트를 해본 입장에서 이 테스팅 과정이 자동화 되어있다면 아주 편할 것 같다.
배포는 테스팅 완료된 코드가 애플리케이션으로 만들어졌으니 이것을 상품화해서 배포한다고 생각하면 된다. 개발자가 변경사항을 적용시키면 몇 분 내에 애플리케이션을 이용할 수 있는게 기준이라고 한다. 확실히 말로만 들었을 땐 꼭 필요한 것이고, 앞으로 프로젝트에도 적용시키려면 어떻게 할지 연구해봐야겠다.
마무리하며
CI/CD 에 대해 정말 궁금했었는데 어느정도 정리가 되었다. 누군가 CI/CD 를 어떻게 구성했냐고 내게 물어보면 CI는 Github를 통해 했었지만 CD를 하기엔 무리가 있었다고, Window 환경에서 배포해봤다고 대답하겠다. Docker와 Kubernates를 공부하면 좀 근사하게 답변할 날이 올거라고 생각한다.
참조 및 읽을거리
RedHat : what-is-ci-cd
CI/CD란 무엇인가 (Feat. DevOps 엔지니어) - 개발자 김모씨
데이터 기반으로 지속적인 CI/CD 개선 환경 만들기 - 구상모씨
GitOps and Kubernetes - 지구별 여행자
