[17주차 Day2] 모니터링 도구 기초

반 히·2024년 6월 21일

데브코스

목록 보기
50/58
post-thumbnail

📚 Part 4 CI 파이프라인 구축


📁 CI 파이프라인 기초

📌 CI 파이프라인

  • "파이프라인(pipeline)"에 대한 추상적 수준에서의 정의
    • docker build → docker push → kubectl create → kubectl expose
  • 상세 수준에서의 정의
    • Jenkins를 통해 자동화한 빌드 단계와 그 절차

📌 간단한 파이프라인 구축 실습

  • 예제 응용
    • 두 수가 주어지면 이에 대한 덧셈 연산을 행하는 것을 웹 응용 (Spring Boot) 으로 만들어서 이용
      • 이번 강의와 실습에서는 아직 기능 구현은 하지 않음
    • 입력은 query string 으로, 출력은 그냥 날것의 텍스트로
  • 실습 단계
    • GitHub 에 code repository를 생성, 설정하고 초기 소스 코드를 (비롯한 파일들을) 등록
    • Gradle 을 이용한 빌드 환경을 설정 (JDK 필요)
    • 응용에 알맞은 빌드 환경을 컨테이너 이미지로 제작하고 이것을 Jenkins agent 에 포함
  • 다음 강의에서는
    • 파이프라인에 단위 테스트 단계를 추가하고 테스트 리포트 발행 (Jenkins 로 자동화)

📌 GitHub 접근용 SSH Key 생성

  • GitHub 의 비공개 (private) repo에 접근할 때는
    • https 보다 ssh 프로토콜을 더 많이 이용
    • Username/passwd 에 의한 인증보다 SSH (또는 GPG) key 에 의한 인증을 더 많이 이용

ssh-keygen을 이용하여 public-private keypair를 생성하고 (이미 갖고 있으면 그것을 사용)
1. GitHub 로그인
2. (Account) Settings >> SSH and GPG keys
3. New SSH Key
4. 공개 key (기본적으로 id_xxxx.pub파일로 생성됨) 등록
주의) 비공개(private) key는 노출되지 않도록 주의해야 함

📌 빌드 에이전트의 개선

  • 커스텀 에이전트 컨테이너를 만들어 적용해 보자
    • 빌드에 필요한 환경을 미리 구축
    • 어느 Jenkins CI 환경에 적용해도 동일한 환경 적용
    • 이후에 복잡한 여러 단계를 거치는 빌드 과정에 대응하는 데에도 유리
  • 에이전트 컨테이너 준비 과정
    • Dockerfile 작성
    • docker build && push
    • 위에서 레지스트리에 등록한 이미지 적용


📁 CI 파이프라인 - 단위 테스트

📌 단위 테스트

  • 단위 테스트의 중요성
    • 코드 (를 포함해서, 복잡한 구조를 가지는 구현물)의 개발에 있어서는 "잠재적 결함을 일찍 (앞선 단계에서) 발견할 수 있을수록" 효율 (및 안정성) 이 높아짐
  • 쓰여진 모든 코드는 테스트되어야 함 - 테스트 커버리지와 연관 → 다음 실습에서 커버리지를 다룰 것
  • 단위 테스트는 개발자의 몫
    • 직접 코드를 구현하는 개발자만큼 해당 코드의 어떤 측면을 어떻게 테스트해야 하는지를 잘 이해할 수 있는 다른 사람이란 없음
    • 이것은 통합 테스트 및 인수 테스트와는 구별되어야 하는 것으로서, 테스트 케이스를 명확히 정의하고 이것을 테스트 케이스로 구현하는 것은 코드 개발자가 담당
      • 이것을 조금 더 깊이 고려하면 TDD (Test-Driven Development) 방법으로 연결할 수도 있음


📁 CI 파이프라인 - 코드 품질 확보

📌 코드 품질

  • 코드의 품질이란 무엇인가?
    • 기능성 - 의도한 (요구된) 기능을 모두 올바르게 수행하는가?
    • "올바른" 코드 말고, "좋은" 코드란 어떤 것인가?
      • 대충 얘기하면, "읽기 좋은 코드", 또는 바꾸어 말하면 "엔지니어링 관점에서 재활용성이 높은 코드"
  • 실행 시점이 아닌, 그보다 이전에 정의할 수 있는 코드의 품질은 어떤 것들이 있을까?
    • 단위 테스트가 잘 마련되어 있는 코드 - 테스트 커버리지 (test coverage)로 측정
    • 규칙(?)에 따라 잘 쓰여진 코드 - 컨벤션 (스타일 가이드라인) 준수 정도로 측정

📌 코드의 작성에 적용되는 규칙

  • 모든 프로젝트에 같은 규칙이 적용되는 것은 아니지만, 같은 프로젝트를 행하는 개발자들 사이에서는 통일된 규칙을 제정하고 준수하는 것이 매우 중요

0개의 댓글