학습주제
학습내용
CI/CD를 학습하고
github actions를 사용
빌드?
소프르웨어를 배포하기 이전에 패키지로 만드는 것.
테스트가 중요한 일부가 됨. 테스트가 다 성공하면 배포하기 위한 패키지로 만듦.
도커 이미지 - 패키지
다양한 테스트를 붙이는게 소프트웨어 안정성 증대
커밋 할때마다 테스트 돌려봄
CI - 계속적 통합.
코드를 고치고 반영할 때마다 안정성을 보증.
작은 회사에선 이 베스트 프랙티스를 적용하기 어려움.
좀더 공격적으로 다양한 기능을 만드는게 더 효율적.
엔지니어링 팀에 충분한 인원이 있을 때 가능.
테스트 코드가 하나라도 실패하면 빌드는 실패
기본 원칙
코드 리포는 하나만 유지 (master, main)
새로운 기능을 추가할 때 복사본, 브랜치를 만들고 작업을 한 다음 마스터에 merge
코드변경을 할 때 한달동안 작업해서 한번에 끝내려고 하지 말고, 작은 브랜치 만들어서 일부기능 변경후 master에 merge 자주 싱크해라. 안그러면 너무 고생하게 됨. 코드변경을 가끔하면 리뷰하는 사람도 고생임.
테스트를 최대한 추가.
테스트 커버리지 75% 면 코드 75%가 커버됨. 보통 저렇게 정량화 해놓고 테스트 만들어둠.
코드의 품질을 계속 체크할 수 있음
CI 결과로 모든 테스트가 성공 -> 배포(CD)
CI/CD. 성숙한 웹서비스의 경우 적용. 코드한줄 바꿔서 push 했다면 CI를 생성, 테스트 성공했다면 패키지 만들고, 프로덕션에 배포됨.
CI/CD를 쓰는 곳들이 많음. 하루에도 수십번씩 프로덕션에 코드배포가 이뤄짐. 테스트 커버리지가 충분해야함.
빌드가 다시 성공할 때까지 모두 코드변경 못함.
뒤에 기다리는 사람 생김.
약간의 패널티를 줘서, 빌드실패는 심각한 문제라는 인식을 심어줌.
개발자의 수가 100명이 넘어가고 같은 리포를 가지고 작업하다보면 빌드가 실패했을 때 누가 범인인지 알아내기 힘들어짐 - 전담 엔지니어가 있음.
개발자가 많아지면 코드 품질이 내려감.
내가 만든 코드 push 전에 로컬에서 테스트 돌려보는 습관 갖기.
코드를 커밋을 하면, 다양한 테스트를 하고, 다 성공을 하면 패키지로 만들어서(도커 이미지) 그걸 가지고 프로덕션 서버로 새로운 소프트웨어를 배포함.
코드변경이 생길 때마다 계속해서 일어나게 됨.
이걸 책임지는 데브옵스 팀이 있어야 함.
배포 과정 자동화하고 모니터링하면서, 문제시, 이전 버전으로 롤백.
프로덕션 서버는 점점 쿠버네티스 서버 사용으로 가는 중.
