-
[내일배움캠프] 2월 6일 월요일 TIL 회고록카테고리 없음 2023. 2. 6. 23:53
오늘은 대망의 마지막 팀 프로젝트를 시작하는 날이었다.
프로젝트 발제를 다 들은 후 새로 배정받은 조에 가서 간단한 인사를 나눈 뒤 최종프로젝트 S.A를 만들었다.
처음에 각자 프로젝트를 어떻게 만들지 30분동안 고민 후 한명씩 차례대로 발표하기로 했다.
나는 내일배움캠프 동영상 면접을 볼때 말했던 비전공자와 전공자가 서로 교류하며 정보를 교류하는 사이트를 만들어 보고싶어 대충 정리해봤다.
한명씩 차례대로 발표 후 서로서로 괜찮은 것들을 하나로 모아 짬뽕식으로 만들기로 하였다.
그 후에 어떻게 해야할지 모르겠는 것들은 튜터님들한테 가서 물어봤다.
와이어 프레임, ERD를 작성하거나 기능들을 생각하다보면 기능들이 점점 늘어나서 도저히 하루만에 깔끔하게 만들기는 쉽지 않아
틀만 잡고 내일 이어서 만들기로 하였다.
CI/CD 개념 정리
CI/CD : 간단하게 말해서 어플리케이션 개발 단계부터 배포 때까지 이 모든 단계들을 자동화를 통해서 조금 더 효율적이고 빠르게 사용자에게 빈번히 배포할 수 있도록 만드는 것이다.
CI : Continuous Integration, 지속적인 통합의 약자
CD는 두가지 의미로 사용된다.
CD : Continuous Delivery , 지속적인 제공의 약자
CD : Continuous Deployment : 지속적인 배포의 약자
CI의 두가지 포인트
- 개발자들은 코드 변경사항을 주기적으로 빈번하게 머지해야 한다.
- 통합을 위한 단계 (빌드,테스트,머지)의 자동화
CI 원칙을 따라갔을때에 장점
- 주기적으로 머지를 하므로 머지 충돌을 피할 수 있어서 개발 생산성을 향상시킬 수 있다.
- 머지되는 모든 코드들은 자동으로 빌드되고 테스트되기 때문에 코드에 결함이나 문제점을 빠르게 발견할 수 있다.
- 이렇게 발생되는 결함은 빠르게 수정이 가능하다. (주기적으로 머지를 하기 위해서 코드에 변경사항이 잦기 때문에 문제를 수정할때도 좀 더 고립된 작은 단위에 문제를 확인할 수 있기 때문에)
- 마지막으로 이런 것들을 통해서 조금 더 나은 코드의 퀄리티를 가질 수 있다. ( CI를 잘 운영하기 위해서는 모든 개발자들이 자신이 새로 작성한 코드에 한해서는 유닛 테스트를 꼭 포함해야 하기 때문이다.)
Continuous Delivery, Continuous Deployment 는 각각 서로 연관있고 또 함께 섞어서 사용하는 경우도 있기 때문에 비슷하다고도 볼 수 있다. 둘 다 마지막 배포 단계에서 어떻게 하면 자동화해서 배포를 만들 수 있을지를 고민하는 단계이다.
CI/CD 의 파이프라인 :
CODE -> BUILD -> TEST -> RELEASE -> DEPLOY
CODE : 개발자가 작은 단위로 기능을 나누어서 주기적으로 메인 레포지토리에 머지를 하면,
BUILD : 자동으로 빌드를 하고,
TEST : 테스트 단계를 거쳐서
RELEASE : 릴리즈 준비를 한다.
DEPLOY : 여기서 수동이나, 자동으로 최종 배포를 거치게 된다.
Github Actions : 깃허브가 만든 자동화 (CI/CD) 시스템
깃허브 액션 정리
Github Actions의 5가지 개념
- Events : 특정한 이벤트가 발생했을때 내가 원하는 일을 자동으로 수행할 수 있도록 만들어주는 도구이다. 그렇기에 어떤일이 발생했는지 지정할 수 있는 Event가 있다. Event는 깃허브에서 발생할 수 있는 대부분의 이벤트를 지정할 수 있다. 내 PR을 메인 브랜치로 머지할 때 어떤 테스트를 수행해야 한다면 그 이벤트를 지정해 줄 수 있고, 또는 커밋을 푸쉬를 하거나 또한 새로운 이슈를 누군가 만든다면 그때 수행해야 하는 일이 있다면 그 Event들을 다 지정할 수 있다. 특정한 이벤트가 발생했을때 내가 어떤 일을 수행할 수 있냐를 명시하고 싶은 것이 Workflows이다.
- Workflows : Events에서 push라는 이벤트가 발생하면 Workflows에 지정된 것들이 수행이 된다. Workflows는 한마디로 요리책 같은 건데 내가 파스타가 먹고싶다는 이벤트가 발생하면 파스타를 만드는 레시피 책을 보는 것처럼 Workflows를 이용할 수 있다. 이 Workflows에는 Jobs이 있다.
- Jobs : Workflows에 있으며 하나 또는 다수의 Jobs을 가지고 있을 수 있다. 이 하나의 Jobs 는 무엇을 한다. (ex : Unit Test, E2E Test) Jobs는 병렬적으로 동시다발적으로 실행이 된다. 만약 한개의 Jobs이 끝난 다음에 또 다른 Jobs이 실행되야 된다면 순차적으로 진행될 수 있도록 만들 수 있다. 그리고 각각 Jobs 안에는 어떤 순서대로 Jobs이 실행이 되는지 Step을 하나하나씩 명시해줄 수 있다. Shell Script를 사용해서 어떤 Step을 해야되는지를 명시해줄 수 있고, npm install, npm 같은 명령어도 수행할 수 있다. 그리고 Github Actions에서 제일 중요한 Actions를 사용할 수 있다.
- Actions : Github Actions 에서는 우리가 재사용할 수 있는 공개적으로 오픈된 액션들이 많이 있다. 그래서 우리가 흔하게 사용할 수 있는 다양한 명령들이 이렇게 액션으로 정의되어 있기 때문에 action check out, Repository를 check out 해서 우리가 원하는 명령을 수행할 수 있고, action check out을 한 다음 action setup node를 사용하면 자동적으로 node 환경을 셋업할 수 있는 코드들이 실행이 된다.
- Runners : Jobs을 실행하는 것이 Runners 이다. Runners는 VM 머신이라고도 볼 수있고, 다커 컨테이너라고도 볼 수 있다. 그래서 각각의 Jobs 들은 개별적인, 독립적인 Runners라는 컨테이너에서 실행이 된다.
CI/CD 및 Github Actions에 대해 유튜브를 참고하며 정리 해 보았다.
내일 시간이 날때 다시 한번 더 봐야겠다..