#10 CI/CD

CI/CD로 Release 최적화
 - 지속적 통합(CI) >> 개발 주기 단축
  : 다양한 도구를 통해 작업의 간소화 및 효율화 모색
   > Ansible, Serverspec 등을 이용한 작업의 코드화 -> 반복 가능하게 됨
   > 일련의 일을 자동화 -> Gitlab-Runner / Github-Runner /...
  : 노력의 간소화가 상당 부분 가능해짐

 - 개발 절차 : "개발하고 테스트하고 출시"는 잘못된 말 (test결과에 따라 출시가 안 될 수 있음)
  : test의 결과가 Not Good인 경우
   > 위의 문제를 조기에 발견 및 빠른 대처
   > 일련의 작업 간소화 -> 개발 주기의 전체 효율성 상승

 - 문제 조기 발견의 계기
  : 문제가 발견되는 경우 = "소프트웨어 개발 / IaC -> 코드 변경"
  : 따라서, 코드 변경 시점 -> Deploy / Testing / Release 와 같은 일을 수행해야 함
   > 자동으로 위의 활동이 가능하다면 -> 문제점 해결에 집중 가능 -> 개발 전체의 효율화 진행 가능성 상승

 - 지속적 통합(CI : Continuous Integration)
  : 목적 - 전체 개발 주기를 간소화
  : Build -> Test -> 품질 검사
   > 기능 구현에 관련된 작업을 계속적이고 자동으로 실시
   > 소프트웨어 및 서비스가 작동하는지 세세하게 확인하면서 개발 진행

 - CI의 장점
  1. 문제의 조기 발견과 그에 따른 품질 유지
   기존) 여러 번의 commit후 임의의 시점에 Test : Test 시점에서 대량의 버그 + 대량의 수정 발생
   CI 도입) 매 Commit마다 test 진행 가능 > 자동화되어 있기 때문
  2. 작업 비용의 절감 : 자동화로 인한 개발자 노력의 감소
  3. 상황의 가시화
   > 중앙 집중식 동작
    : 코드 변경으로 인한 테스트 결과를 쉽게 확인 가능 
    : DevOps의 전제 > 정보의 투명화에 합치

 - CI로 얻을 수 있는 것
  : "테스트가 항상 실행되고 있는 상태"의 유지
  : 통과했다면 문제가 없는 결과물이라는 것

 - 서비스의 제공 목표
  : 테스트 수행이 아님(CI로 얻을 수 있는것과 다름)
  : 운영 환경에 Release 하여 사용자(고객)에게 가치를 전달 하는 것

 - 지속적 딜리버리(CD: Continuous Delivery)
  : 지속적 통합과 같은 점 > 일련의 작업을 자동화
  : 다른 점 > 대상 범위
    - CI -> Test까지 자동화(기능 테스트 위주)
    - CD -> 운영 환경에 Release "직전" 까지를 자동화(운영 테스트 까지 진행)

 - CD의 목표 : 빠른 Release
  : CI > "테스트를 수행한다"가 목표
         > 테스트가 정상적으로 성공했다면 오류 없는 결과를 의미
  : CD > "모든 테스트를 끝낸다"가 목표
          > 모든 테스트가 성공했다면 배포 가능한 상태임을 의미

 - CD 테스트의 종류 : 다양한 테스트를 반복하고 Release 준비
  : 단위/통합 테스트 > 애플리케이션에 구현된 각 기능이 제대로 작동하는지 확인
  : 보안 테스트 > 애플리케이션의 보안 취약점이 없는지 확인
  : 성능 테스트 > 애플리케이션이 요구되는 성능을 낼 수 있는지 확인
  : 부하 테스트 > 애플리케이션에 일정 이상의 부하를 주었을 때, 문제가 일어나지 않는지 확인 
  : 장애 테스트 > 애플리케이션 및 주변 환경에 손상을 준 경우 사전에 정의해 둔 장애 대응 동작을 하는지 확인
  : 릴리즈 테스트 > 요청된 이미지대로 애플리케이션이 구현되었는지 확인
  : 인수 테스트

 - CI/CD 구분

 - CI/CD에서의 테스트
  : CI/CD 모두 정해진 테스트를 진행해야하는 것은 아님
   > 특정 테스트 요건을 지정하고 있지 않음
  : 애플리케이션, 상황 요건에 맞게 선택하여 CI/CD 실현
   > 특별한 이벤트에 하는 것은 제외
   > 일상적으로 반복적으로 해야하는 것을 선택해야 함

 - CD(지속적 딜리버리)
  : 코드 변경 -> 필요한 테스트 모두 통과시
    > 운영 환경에 Release 가능한 상태를 의미 (Release가 된 것이 아님 > Release 작업을 해야 함)
    > 코드를 Release 작업 수행 가능
     = 애플리케이션 전환(Packaging / Installer 등) 후속 작업
     = 운영환경으로 Release
  : 운영환경에 대해 Release를 포함하지 않는 이유
    > 실 사용자에게 영향이 감
    > 사람의 판단에 따라 시점을 조절하여 수행할 수 있도록 하기 위한 의도
     (시점 조절이란? > 사업적 판단 등을 고려함을 의미)

  : 지속적 디플로이(Continuous Deploy)
   > Release의 시점이 개발자에게 위임된 경우
    : Release 까지 자동화 범위에 포함 가능(포함한 상태를 지속적 디플로이라 함)
  

 - CD(지속적 디플로이 - Continuous Deployment)
  : Continuous Delivery 보다 진보적 구조 필요
   > Release : 애플리케이션 중단 교체 시간 필요
   > Release가 언제 발생해도 상관 없도록 설계 필요

 -정리
  CI : 코드에 문제가 없는 상태를 유지 시킴
  CD(Delivery) : Test 완료 되어 설치 가능 및 운영할 수 있음을 보장
  CD(Deploy) : Release를 포함

팀 단위의 DEVOPS 적용
 - 팀 개발과 커뮤니케이션을 효율화 > VCS (ex, Github), Jira, SNS 시스템 등
  - 쉽게 Local 개발 환경을 만들고 공유 > Vagrant / Docker ...
 - 작업을 정형화하고 이력을 관리 > Github(GitLab) Runner ...
 - 빠른 피드백과 빠른 릴리즈 > CI/CD