github actions를 이용한 ci/cd 과정
1. CI/CD
어플리케이션 개발단계부터 배포 때까지 이 모든 단계를 자동화를 통해,
더 효율적이고 빠르게 사용자에게 빈번이 배포할 수 있도록 만드는 것.
CI =Continuous Integration(지속적인 통합)
CD=Continous Delivery(지속적인 제공)
=Continous Deployment(지속적인 배포)
1-1. Continous Integreation(지속적인 통합)
버그 수정이나, 새로 만드는 기능들이 메인 레포에 주기적으로 build, test 되어서 merge 되는것을 말한다.
포인트 두가지 생각하기
1. 코드 변경사항을 메인 레포에 주기적으로 빈번하게 머지해야한다.
동일한 소스파일 위에서 두명이 서로다른 코드를 작성하고 있다가,
나중에 머지하려하면, 서로 다른 코드를 어떻게 통합하여 적용할 지에 대해 고생을 함.
->머지 충돌해결에 시간이 많이 소요된다.
-버그수정, 새 기능 구현시
기능을 작은 단위로 나눠서 메인 레포에 반영.
작은 단위로 나눠 사용자에게 배포할 수 있을지/작은 단위로 나누어서 개발하고 통합하는 것이 중요함.
2. 통합을 위한 단계(빌드, 테스트, 머지)의 자동화
주기적으로 머지된 코드의 변경사항이 자동으로 빌드되어서
코드 변경 이후에도 빌드가 성공적으로 되었는지 확인이 되어야하고,
새로 추가한 코드의 변경사항 뿐 아니라,
기존의 시스템에 다른 버그를 초래하지 않았는지 자동으로 테스트까지 되어야한다.
보통 개발팀에서 이런식으로 많이 셋업함.
메인레포가 있고 개발자들은 하루에도 몇번씩 코드의 변경사항을 메인레포에 머지함.
그 전에 코드리뷰로 코드가 적절한지 확인
머지 이후 자동으로 팀에서 만든 ci스크립트를 통해 추가된 코드와 함께
레포빌드->팀에서 작성한 uni,integrationg 테스트가 스크립트를 통해 실행된다.
이렇게 빌드, 테스트 성공 시 green 초록사인-> 무사히 통과 배포시 반영
문제가 있어서 빌드실패,테스트 실패시 -> red sign이 뜨면서 문제를 일으킨 개발자에게 자동으로 알려준다.
3. ci 원칙을 따라갔을떄 장점
- 주기적 머지
머지 충돌을 피할 수 있어서-> 개발의 생산성향상
- 머지되는 모든 코드들은 자동 빌드, 테스트
코드의 결함이나 문제점이 빠르게 발견, 이렇게 발생되는 결험은 빠르게 수정됨
(주기적으로 머지를 하기위해 코드의 변경사항이 작기떄문에 문제수정시 작은단위 문제를 확인)
조금더 나은 코드의 퀄리티 향상
(모든 개발자들이 자신이 작성한 코드에 대해 유니테스트를 실행해야하기 떄문)
ci를 사용하면 프로젝트 대부분의 소스코드들이 자동으로 테스트 될 수 있게 만들기에
좀 더 안정성있는 제품개발
1-2. cd=continous delivery=continous deployment
각각 서로 연관 있기에 비슷하다고 보면됨
마지막 배포단계에서 어떻게 자동화하여 배포할 수 있을지 고민
1. continous delivery
ci 를 통해 주기적을로 머지된 코드 변경사항이 자동 빌드, 테스트 후
배포하기 위한 준비과정 ->준비된 release 가 문제없는 지 검사후
-> 최종적으로 배포결정후 수동적으로 배포하는단계 delivery
2. continous deployment
release 준비되자마자 자동으로 사용자에게 배포
-> 모든 과정을 자동화하는건 deployment
최종단계 자동화 여부에 따라 살짝 다름
ci/cd 라 해도
3. 어떻게 모든 과정을 자동화 해두고 스크립트 작성하냐에 따라 회사마다 다름.
2. CI/CD
2-1. ci.cd
둘 다 거쳐 배포하기에 묶어서 부른다.
파이프라인 정리
1. 개발자가 작은 단위로 기능을 나누어서 주기적으로 메인레포에 머지
2.자동으로 빌드
3.테스트과정을 거쳐
4. 릴리즈준비를 함
5. 수동/자동으로 최종배포
2-2. ci.cd tool
회사마다 다름.
3. GitHub Actions
3-1. GitHub Actions 의 5가지 개념
Events Workflows Jobs Actions Runners
(특정 이벤트 발생 시 내가 원하는 일을 자동으로 수행하게 해주는 툴)
1. Events
어떤 일이 발생했는지를 지정함.
깃허브에 발생하는 대부분 이벤트를 지정
2. Workflows
특정 이벤트 발생 시 내가어떤일을 수행할수 있는지(자동화된 스크립트)
push 라는 이벤트 발생시 workflow에 지정된 것들이 수행됨(요리책)
내부에 하나이상의 job존재
3.job
하나의 job은 무언가를 함
job들은 동시다발 적 수행함.
job 내부에는 어떤 순서대로 수행하는지 스크립트를 명시
쉘 스크립트를 사용해서 어떤 스탭을 해야하는지 명시
+깃헙에서 제공하는 유용한 aciton 이용
4. actions
=npm에서 라이브러리를 가져와 쓰는것과 유사
깃허브 엑션에는 재사용가능한 공개적 오픈된 action
흔하게 사용할 수 있는 명령어 action이 저장됨
actions checkout=레포를 체크아웃->원하는 명령어 수행
actions checkout ->action setup node->자동적으로 노드환경을 셋업
5. runners
병렬 실행되는 job을 실행하는 것이 runner이다.
runner 은 vm machine이라고 볼 수 있고, docker container라고 볼수도 있음
각각의 job은 독립적인 runner라는 컨테이너에서 실행됨.