Docker & K8S - CI/CD

 

학습 목표

 

CI/CD의 개념과 가장 많이 사용되는 소스 컨트롤 시스템

 

Git과 Github에 대해 알아보고 Github이 제공하는 CI/CD 서비스인

 

Github Actions에 대해 알아보려 합니다.

 

 

이렇게 배운 개념들을 바탕으로

1. Github Actions로 Hangman 코드에 테스트를 붙이는 실습

 

2. Github Actions를 통해 Docker Image를 만들고 Docker hub에 push하는 실습

 

2개의 실습을 하려합니다.

 

 

 

 

Docker와 K8S 공부 도중에 CI/CD 이야기를 하는 이유는

먼저 아주 간단하게 설명드리자면 CD에 Docker Image가 많이 사용되고 프로덕션 서버환경이 점점 K8S와 같은 container orchestration 플랫폼이 사용되기 때문입니다.

 

 

 

 

 

 

 

CI/CD 설명에 앞서 소프트웨어 빌드에 대해 설명하려 합니다.

 

소프트웨어 빌드란?

자신(혹은 팀)이 개발한 소프트웨어를 최종적으로 출시하기 위한 형태로 만드는 것

테스트가 빌드의 중요한 일부로 포함됩니다. 그래야만 누군가 실수해도 테스트로 이를 잡아낼 수 있기 때문입니다.

테스트가 전부 통과하면 그때 소프트웨어를 배포하기 위한 패키지로 만듭니다. 이 때 많이 사용되는 패키지 포맷이 Docker Image입니다.

 

하나의 test라도 실패하면 그 테스트는 fail(실패)한 것으로 간주합니다.

 

참여 개발자들이 많을수록 이는 더 중요

 

개발이 끝나기 전부터 빌드를 하면 소프트웨어의 안정성 증대

개발자가 코드를 고칠 때마다 테스트를 돌려 우리가 기대하는대로 코드가 동작하고 있다는 것을 보장하는 것이 필요하고 이를 Continuous Integration(CI)라고 합니다!

 

 

 

 

 

 

 

 

소프트웨어 빌드와 왜 CI가 필요한지 살펴보았으니 CI에 대해 더 자세히 살펴보겠습니다.

 

Continuous Integration이란?

Software Engineering Practice의 중의 하나

 

기본 원칙

1. 코드 Repo는 하나만 유지 (Master 혹은 Main)

Main 브랜치에서 새로운 branch를 생성하고 그곳에서 작업을 진행해야 안정성이 높습니다.

2. 코드변경을 최대한 main 브랜치에 자주 반영

너무 오랫동안 반영하지 않으면 main 브랜치와 합쳐야 할 브랜치가 너무 달라지게 되고 merge할 때 문제가 생길 확률이 높습니다. 또한 그래야 코드 리뷰가 쉬워집니다.

3. 테스트를 최대한 추가

    - Test Coverage: 예를 들어 75%라면 전체 코드의 75%가 테스트로 커버되었다는 뜻입니다. 많은 조직들이 저마다의 최소 test coverage 정하고 코드 빌드를 하는 것이 일반적입니다.

 

4. 빌드를 계속적으로 수행 (자동화)

새로운 push를 할 때마다 자동적으로 코드 품질 test를 수행합니다.

    - Commit Build vs. Nightly Build

 

5. 성공한 빌드의 프로덕션 릴리스 (자동화)

CI에서 한단계 더 나아가 모든 test 결과가 통과되고 패키지가 만들어졌다면 이를 자동으로 배포하며 이를 CD라고 부릅니다. CD: Continuous Delivery

 

 

 

CI/CD가 함께 묶여 언급되는 이유

 

코드 한 줄을 바꿔 push하는 상황을 예시로 들겠습니다. 이런 상황은 소프트웨어(코드) 빌드로서 CI(git merge)를 생성시키고 CI 과정으로서 모든 테스트가 통과되고 패키지가 만들어졌다면 이를 자동으로 배포하는 CD를 수행합니다.

 

즉, 프로젝트를 위해 여러 개발자가 모여 협업하는 모든 과정 하나하나를 전부 CI/CD로 볼 수 있기 때문입니다.

 

 

 

 

 

 

 

 

 

 

만약 빌드가 실패하는 경우는 어떨까요?

 

빌드 실패! 

새 코드의 커밋으로 인해 테스트가 실패하는 경우

commit한 코드가 하나 이상의 테스트에 실패한 경우이고 많은 기업들은 이를 고칠 때까지 다른 사람들의 코드 변경을 금지합니다.

 

많은 회사들이 빌드 실패시 빌드가 다시 성공할때까지 코드 변경을 금지

즉 빌드 실패는 모든 사람들을 잡아두는 족쇄
그래서 어느 정도 조직이 커지면 범인을 찾기 힘들어져 범인 색출과 빌드만 전담하는 엔지니어가 생김
    - 이 사람의 업무 중의 하나는 빌드 실패시 누가 주범인지 알아내는 것 ☺
빌드실패시 가벼운 형태로 페널티 부여

 

 

 

 

 

 

 

 

 

 

 

즉, CI/CD란?

 

 

개발자가 코드를 commit하면 다양한 종류의 테스트를 진행하고 (CI)

테스트가 끝나면 소프트웨어를 배포하기 위한 패키지(주로 Docker Image)를 배포하는 것 (CD)

 

안정적인 CI/CD에는 성숙한 엔지니어링 팀과 CI/CD 과정을 책임지는 DevOps팀이 필요합니다.