#8 Build Pipeline 관리

Vagrant : Cloud 적용 가능
 > VM 초기 구축
 > 프로비저닝 : 활용 준비 > Script로 작성(속인성 문제)

Ansible : 구성관리 도구(Script 문제를 해결)
 > YAML로 "선언적" 기술(Script는 절차를 기술)
 > Task(작업)을 Role로 정의(변수, 파일, 템플릿 포함)
 > 작업의 대상 : Inventory(인벤토리)
 > 간단히 미리 정의된 형태(= 코드)로 사용 : Git / Review등이 가능

Serverspec
 : 인프라 구축 테스트
 : Ruby로 작성(Ruby dsl), rake 명령어로 실행

Vagrant => Code
Ansible => Code          --> Text --> Git/형상관리 | Review 가능
Serverspec => Code

변화 탐지 > 동작하는지 테스트 + 실행 자동화 

Build Pipeline
기존 구성 관리 도구
 > Ansible, Serverspect : 신속한 자동 구축, 반복적 사용, 테스트 가능

새로운 과제
1) 명령어 조작을 간단하게 하고 싶음 (명령어를 기억해야하고, 사용을 잘 해야함(정확한 입력))
 : Ansible을 사용한 구축 + Serverspec을 사용한 테스트
  > 서버에 로그인
  > 명령어 입력 및 수행
  > "반복적 작업" : 이 작업도 줄일 수 없을까?

2) 구축 작업을 보다 안전하고 확실하게(=실수없이) 하고 싶음
 : 인프라 구축은 조금만 잘못되어도 큰 영향을 미침
  > 매개 변수를 잘 못 설정
  > 절차상의 오류 발생
  > 사람의 "수작업"과 "판단"이 개입 : 이를 제거해야 잘못 입력할 수 있는 여지를 없앨 수 있음
  > 필요한 테스트도 강제 수행 : 수동으로 하면 오래 걸림

3) 구축 및 테스트 결과와 이력을 축적(보존)하고 팀에서 확인하고 싶음
 : Git > 코드 변경에 대한 이력은 축적
         > 실행 이력은 축적하지 않음
 : 어떤 "작업 -> 결과"를 확인할 수 있어야 "장애 발생"시 원인 조사가 가능

Build Pipeline 도구는 앞의 3가지 새로운 과제를 해소 + GUI를 통해 작업 수행(명령어에서 해방)

Build Pipeline 도구
Pipeline
 : 파이프들의 집합 > 사방으로 연결 = 일련의 프로세스를 자동화 수행
 : 다양한 처리(구축, 테스트 등)를 정의

PipeLine

예시
1. Jenkins(https://jenkins.io)
- OpenSource로 공개 
- CI/CD 툴 중 가장 오래, 널리 알려진 툴

 > Jenkins는 Plugin 형태로 확장 가능 하도록 해 줌
 > 원하는대로 쉽게 커스터마이징 가능(자유도가 높음)

2. Circle CI(https://circleci.com)
- Cloud기반 CI/CD
- Trigger Server와 Build Server

Circle CI

 > 젠킨스 차이점
  : 빌드 환경(절차)을 config.yml이라는 파일로 저장
  : 파일이 Repository에 저장됨
  : API는 Repository의 변경을 보는데 config.yml의 존재 여부에 따라 동작 진행 결정
   > 동작 한다면 어떤 workflow를 쓸 것이고 어떤 시스템을 결합해야 하는지 등을 판단

3. Drone CI(https://drone.io)
4. Travis CI(https://www.travis-ci.com)

1~4 사용 목적
 : Source부분 + Build 서버 (Cloud)
 : Build 서버는 일시적으로 필요함
 : 신속함 > 충분한 Power(서버) 필요
 > 사용한 만큼 결제
 : Build하는 부분만 Cloud화 되어 있음
-----------------------------------------------------
5. Gitlab Runner(https://gitlab.com)
 > Gitlab과만 연동
 > on-premise 버젼(github와 유사)
  : Community
  : Enterprise
  > Jenkins와 개념 유사
  > 하지만, Circle CI처럼 매커니즘이 뒤쪽에 있음(클라우드 화 된 것처럼 사용)
  > 또한, 오픈 소스로 사용
  > 설정이 Jenkins보다 간단하면서도 on-premise로 사용 가능함

도구의 특징
1. Jenkins
 - 사내 git / svn 등의 형상관리 시스템이 존재
  : 사내 형상관리 시스템과 연동
  : 외부 시스템을 사용할 수 없을 때
 - 다양한 플러그인과 리포트의 생성 > 매우 다양한 구성 가능
  : 이를 처리할 수 있는 인력이 존재(필요함)

2~4. Circle CI, Drone CI, Travis CI
 - 클라우드 기반의 형상관리 소프트웨어 사용
  : github.com / gitlab.com / bitbucket.org 등
  : CI 설정을 형상관리 도구에 포함(파일로 포함 / config.yml)하여 관리할 수 있음
  : 제공하는 클라우드 환경에서 CI/CD 수행
  : AWS 등의 클라우드 시스템에 손쉽게 배포 가능

5. Gitlab-Runner
 - 호환성이 떨어짐
 - Gitlab 클라우드 / 설치형을 사용하는 경우
  : Gitlab을 사용하고 있다면 사용 가능
  : Circle CI / Drone CI / Travis CI 등과 사용법이 유사

CI/CD의 선택
- 대부분의 CI/CD 도구들은 비슷함
 : 회사/조직/팀이 가진 제약사항에 따라 선택
 : 보안 이슈(외부 시스템 사용 가능 여부)
 : 클라우드 배포 가능 여부
  > 앞서 소개한 모든 도구가 가능하지만, 가능하기 위해 익혀야 하는 기술이 다름
 : CI/CD 도구의 Learning Coast(모든 개발자들이 다룰줄 알아야 함)
- Custom의 경우
 : Ansible / Serverspec 혹은 Docker를 설정하여 문제 해결 필요

CI/CD 도구의 효과
팀 개발을 효율적으로 만들어 줌
 - 명령어 작업을 이전보다 번거로움 없이 수행 가능
  > 미리 정의된 작업(프로젝트) 단위로 처리 작업을 묶음
  > 매번 명령어 수동 실행할 필요 없음 = 선택과 클릭으로 수행 가능
 - 구축 작업을 보다 안전하고 안정적으로 수행
  > 명령어 수동 입력이 없음 = 인적 오류 배제 가능
  > Parameter가 있는 build 요소 사용 = 변동 가능성 요소를 관리
 - 구축 및 테스트 결과와 이력을 축적하고 팀에서 확인 가능
  > 코드 형상과 실행 이력을 연관된 형태로 확인 가능

Build Pipeline 도구들의 특징
Build와 관련된 처리를 연결하여 수행
Build Pipe + Test Pipe

CI/CD 활용
 : 지속적 통합 => 개발 주기 단축
 : Build -> Test -> Format 검사 등 기능 구현
 : 원본 소스가 변경되는 경우, 반복적으로 실시 > 자동화

CI/CD의 장점
1. 문제의 조기 발견으로 품질 유지 가능
2. 작업 비용의 절감
3. 상황의 가시화 가능

CI/CD 구성요소
1. 애플리케이션 정적 테스트
 - 애플리케이션 기동없이 실시할 수 있는 테스트(실행 X)
  > 사람이 하는 Code Review에 해당하는 행위
  > 문법 검사, 코딩 규칙 검사 등
  [정적 테스트 도구]
  - Java : FindBugs, SonarQube
  - Javascript : Closure Linter, ESLint
  - Ruby : Rubocop
  - Golang : Go Meta Linter
  - Python : Pylint

2. 애플리케이션 빌드
 - 빌드를 통해 의존성 문제 확인
  > 빌드가 가능함을 입증 해야 함
  [빌드 도구]
  - C,C++ : make, cmake
  - Java : Ant, Maven, Gradle
  - Javascript : Grunt, Gulp
  - Ruby : Rake
 
3. 애플리케이션 동적 테스트
 - 애플리케이션의 동작(실행) 자체를 테스트
  > 애플리케이션이 정해진 의도대로 동작한다를 입증
  > 충분한 테스트 실시 필요
   ~> 품질에 대한 자신감
   ~> 코드에 포함된 오류의 조기 발견
  [동적 테스트 도구]
  - Java : JUnit, TestNG
  - Javascript : PhantomJS + Jasmine, Mocha + Chai, Karma
  - Ruby : RSpec
  - Python : Pyunit, Pytest

지속적 통합 도구
- 처리를 기동하는 계기 정의
 : 처리를 기동하는 계기를 CI/CD도구가 제공해 줌 = Trigger 역할
- 다양한 처리를 기동
 : 다양한 처리(Pre defined/사전 정의되어 있음)를 execution(실행) 
- 처리 상황 확인 가능 + 결과 축적
 : 결과(Result)를 Report/History로 확인할 수 있음

지속적 통합의 힘을 이끌어내기
1) 많은 처리를 연결해 자동화
 : 모든 프로세스는 가능한 범위에서 자동으로 진행
2) 많은 테스트를 수행
 : 거의 대부분의 문제의 여지가 있는 코드에 대해서는 테스트 코드 작성
 : 테스트를 자동화
 : 코드를 개발할 때 테스트 코드 추가하기
3) 자주 테스트를 수행(자동화)
 : 지속적 통합을 실시할 트리거
  > 시간 : 매일 => 매 시간
  > 커밋 : Push 발생 시
4) 테스트 결과를 즉시 통보
 : 문제의 조기 발견 > 당사자에게 정보가 연결되어야 함
 : 테스트가 종료되었다 | 문제가 있다 등
 : Slack등의 커뮤니케이션 도구와 연동 필요 => ChatOps