쿠키의 개발 블로그

코드를 작성하고 GitHub에 Push한 경험이 있으신가요? 방금 Push한 코드를 서버에 반영하려면 어떻게 해야될까요? 매번 GitHub에서 새 버전의 코드를 다운받고, Jar를 빌드해서 서버에 옮겨주고, 서버를 재시작하는 일련의 과정을 반복하겠죠. 이런 과정이 자동화된다면 얼마나 편할까요? 이번 글에서는 배포를 자동화해주는 CD(Continous Delivery) 파이프라인 구축 과정을 살펴보겠습니다. 글을 시작하기 전에 먼저 CD 파이프라인이 어떻게 동작하는지 워크플로우를 살펴보겠습니다. CD 파이프라인 워크플로우 GitHub 에서 관리하는 레포지토리의 master 브랜치에 코드가 push되면, Jenkins에게 wehook을 날린다. Jenkins가 빌드, 도커 이미지를 생성한다. 생성된 도커 이..

이번 시간에는 CI(continous Integration) 환경을 구축해보겠습니다. 먼저 CI 파이프라인의 워크플로우부터 살펴보겠습니다. CI 파이프라인 워크플로우 개발자가 GitHub 레포지토리에 Pull Request를 올립니다. GitHub는 Pull Request 생성 이벤트가 발생하게되면 Jenkins에 web-hook을 전송합니다. Jenkins가 프로젝트의 빌드 스크립트를 읽어들여 빌드를 진행합니다. 테스트코드를 실행 결과가 실패일 경우, 빌드 fail을 일으킵니다. 테스트 커버리지를 분석하여 80% 미만인 경우, 빌드 fail을 일으킵니다. Jenkins가 빌드 결과를 GitHub에 전송합니다. 빌드 결과에 따라 GitHub의 merge 버튼이 활성화/비활성화 됩니다. Jenkins 서버..

CI/CD란 무엇인가? Wiki는 CI/CD를 다음과 같이 정의하고 있습니다. 소프트웨어 공학에서 CI/CD는 지속적 통합(continuous integration)과 지속적 배포(continuous delivery)가 결합한 사례를 의미한다. CI/CD는 소프트웨어의 개발, 테스트와 배포를 모두 통합함으로써 소프트웨어 버그를 쉽게 찾아낼 수 있으며, 더 빠른 배포 주기를 가질 수 있게 만들어 준다. - wiki CI/CD의 사전적 정의도 중요하겠지만, 저는 경험과 실습을 통해 CI, CD를 다음과 같이 정의내렸습니다. CI(continous integration)는 다수의 프로그래머가 함께 작업하는 환경에서 지속적이면서 쉽게 코드를 통합할 수 있도록 지원하는 개발 환경을 말합니다. CI 에는 빌드, 테..