GitHub News

GitHub의 CI/CD 및 자동화 초보자 가이드 제2장

GitHubKorea 2022. 7. 5. 14:29

안녕하세요 GitHub 한국 총판 단군소프트입니다.

오늘은 저번 시간에 이어서 '​GitHub의 CI/CD 및 자동화 초보자 가이드 제2장​'에 대해서 알아보겠습니다.

저자

GitHub 액션의 일반적인 사용 예 (및 주의가 필요한 이유)

더 알고 싶으세요? 액션과 워크플로우의 차이 등 GitHub 액션 워크플로우의 모든 컴포넌트의 차이를 설명하는 훌륭한 일을 하고 있는 @mishmanners의 이 기사를 체크해 주세요.

 

제 경험으로는, GitHub 액션을 사용하는 일반적인 방법은 4가지가 있습니다(걱정하지 말아 주세요. 저장소에 드롭하여 바로 사용을 시작할 수 있는 사전 작성된 워크플로우 링크가 포함되어 있습니다).

CI/CD의 GitHub 액션 워크플로우

이 시점에서 GitHub Actions의 강력하고 일반적인 유스케이스가 CI/CD를 중심으로 전개되고 있다고 들어도 놀랄 일은 아닙니다.

거기에 있는 유일한 CI/CD 플랫폼과는 거리가 멀어요(그리고 거의 모든 CI/CD 플랫폼을 GitHub 워크플로우에 통합할 수 있습니다)가 GitHub 플랫폼의 다른 부분과의 긴밀한 통합과 트리거 기능에서 얻을 수 있는 이점이 있어요 GitHub 상의 임의의 Webhook에서 떨어진 CI/CD 파이프라인의 임의의 부분입니다.

시작하기 위해 사용할 수 있는 몇 가지 편리한, 사전에 구축된 GitHub Actions CI/CD 워크플로우를 다음에 보여 줍니다.

Node.js 지속적 인테그레이션:

이 워크플로우는 노드 의존 관계 클린 설치를 수행하고 이를 캐시하고 복원하며 소스 코드를 빌드하고 노드의 다양한 버전에서 테스트를 수행하여 인적 오류를 줄입니다. 이것은 Node.js에 고유한 것이지만 다른 프로그래밍 언어용 다른 워크플로우가 있으며, 그것들은 모두 매우 편리합니다.

코드 기반으로 엔드투엔드 테스트를 실행한다:

Cypress, Applitools, Mabl 중 하나를 이용하여 어플리케이션에서 엔드투엔드 UI 테스트를 실행하는 경우에도 GitHub Actions 워크플로우가 있습니다. 코드를 실제 환경에 마지하기 전에 이러한 GitHub 액션을 저장소에 포함하여 테스트 실행을 트리거해 보십시오.

컨테이너 이미지를 AmazonECR에 배포한다:

이 워크플로우는 새로운 컨테이너 이미지를 빌드하여 Amazon ECR에 푸시하고 기본 브랜치에 푸시면 새로운 작업 정의를 Amazon ECS에 배포합니다. 비슷한 GitHub 액션이 Terraform이나 구글 Cloud Platform 등 다양한 플랫폼에 존재한다는 점에 유의하시기 바랍니다.

 


 

릴리스 관리를 위한 GitHub 액션 워크플로우입니다.

릴리스 관리는 CI/CD 파이프라인의 중요한 부분입니다. 단, 완전히 베이크 처리된 CI/CD 파이프라인 없이도 릴리즈를 자동화할 수도 있습니다. 어느 경로를 선택한 경우에도 릴리스 관리에 대한 접근방식을 레벨업하는 데 매우 도움이 되는 2개의 GitHub 액션 워크플로우를 다음에 보여 줍니다.

오류가 발생한 경우 릴리스를 롤백 또는 삭제합니다:

더 많은 문제를 일으키는 새로운 기능 또는 버그 수정을 출시했습니다. 때때로, 저는 제품판을 다운시킨 적도 있습니다(그것은 일어납니다). 이 액션에 의해 릴리스에 오류가 발견되었을 경우에 롤백을 간단하게 개시할 수 있습니다. 즉, 시간을 절약할 수 있기 때문에 빌드 문제를 수정하는 작업에 착수할 수 있습니다.

npm 패키지 자동공개:

이 액션은 지정된 브랜치에 코드를 푸시하면 npm 패키지를 자동으로 공개합니다. 언뜻 보기에는 단순한 일이지만 중요한 시간을 절약할 수 있다는 것을 보장합니다.

 


 

초보자에게 매우 도움이 되는 2종류의 워크플로우를 다음에 제시하겠습니다.

CI/CD 파이프라인의 일부에 대해 이야기하고 있는 경우에도, 통상적인 워크플로우의 일부에 대해 이야기하고 있는 경우에도, 코드를 작성할 때 복수의 툴을 사용하고 있을 가능성이 있습니다. 이 모든 툴이 서로 통합되어 있는지 확인하는 것은 개발작업의 재미없는 부분 중 하나가 될 수 있는데 그것은 중요한 단계입니다.

Slack에 알림을 보낸다:

이 액션은 자주 사용하는 커뮤니케이션 도구를 최신 상태로 유지하는 데 도움이 됩니다(Microsoft Teams를 사용하는 경우 이를 위한 액션도 있습니다). 이 액션을 사용하여 릴리스, 빌드 실패, CI/CD 프로세스, 새로 열린 풀 요청 등에 대해 통지할 수 있습니다.

프로젝트 계획 보드를 저장소에 연결합니다:

Jira, Trello, GitHub 중 어느 문제를 사용하고 있는 경우에도 다수의 GitHub Actions 워크플로우를 활용하여 그것들을 프로젝트에 통합할 수 있습니다. 즉, 빌드가 실패하거나 성공했을 때 새로운 문제와 관련된 코멘트를 자동으로 트리거 할 수 있습니다. 같은 것이 테스트에도 해당됩니다. 이는 개인적으로 프로젝트 계획 보드의 자동 업데이트로 무엇이 기능하고 있으며, 무엇이 기능하고 있는지 추적하는 데 도움이 됩니다.

 


 

커뮤니티 및 팀 관리를 위한 GitHub Actions 워크플로우입니다.

오픈소스 유지보수 및 기업인들과 이야기를 나누다 보면 액티브한 프로젝트, 팀, 커뮤니티 유지에 얼마나 시간이 걸리는지를 여러 번 들었습니다. CI/CD 외에 GitHub Actions는 조직 내에서 반복적으로 가능하지만 많은 경우 수동 작업을 자동화하여 프로젝트나 팀을 대규모로 관리하기 위한 뛰어난 툴입니다.

그런 의미에서 제가 조우했던 몇 가지 편리한 GitHub Actions 워크플로우를 다음에 제시하겠습니다.

액션 실행:

이 단순한 워크플로우를 통해 프로젝트 내 기여자 또는 팀원이 자신을 문제에 할당할 수 있습니다. 또한 프로젝트의 기술을 설명하고 가이드라인을 제공하거나 문제를 맡아준 누군가에게 감사하는, 프리로드된 콘텐츠의 문제에 코멘트하도록 구성할 수도 있습니다.

 

첫 번째 대화:

이 워크플로우는 자신이 설정할 수 있는 프리로드 된 메시지를 사용하여 저장소에 대한 첫 기고자를 환영합니다. 이는 새로운 팀원이나 기여자를 참여시켜 프로젝트에 기여하기 전에 모두가 프로젝트에 대한 기본적인 이해를 갖고 있는지 확인하기 위한 탁월한 방법입니다.

 

Invite Me:

오픈소스 커뮤니티가 더 편리할 수도 있지만 개인적으로는 이 워크플로우가 더 좋습니다. 공동 작업자가 문제에 대해 코멘트할 경우 공동작업자를 공적기관에 초대합니다. 이에 따라 공동 작업자는 초대장을 받아 받아들일 책임을 집니다.

 

저장소에 바로 추가할 수 있는 구축된 스타터 워크플로우

 

위 워크플로우에서는 바쁘지 않을 경우를 대비하여 조금 더 전달하고자 합니다. 스타터 워크플로우 저장소에는 지속적 인테그레이션, 지속적 디플로이, 코드 스캔, 워크플로우 자동화에 바로 사용할 수 있는 사전에 구축된 GitHub 액션이 다수 있습니다. 이러한 워크플로우는 모두 GitHub팀에 의해 구축 및 테스트되고 있으며 정기적으로 갱신되고 있습니다.

제가 개인적으로 좋아하는 것 중 하나는 CodeQL입니다. 이는 GitHub의 정적 코드 분석 엔진을 워크플로우에 내장하여 코드 내에 알려진 보안 취약점을 특정합니다. 또한 작업하고 있을 가능성이 있는 여러 가지 일에 대해서 그 밖에도 많은 사전에 구축된 워크플로우가 있습니다.

사전에 작성된 스타트 워크플로우 중 하나를 시작하는 방법은 다음과 같습니다.

1. 저장소에. github/workflows 폴더를 작성합니다.

2. 그 폴더에. yml 파일을 작성합니다.

3. 프레스타터 워크플로우 내용을 복사하여. yml 파일에 붙여넣습니다.

4. 필요에 따라 파일을 커스터마이징합니다.

5. 액션을 트리거하여 정상적으로 실행되는지 테스트합니다.

 


 

Pro TIP: 니즈에 맞게 미리 작성된 GitHub Actions 워크플로우를 맞춤 제작합니다.

GitHub 마켓플레이스에는 13,000개가 넘는 GitHub 액션이 있기 때문에 워크플로우가 이미 존재하고 있을 수 있기 때문에 워크플로우를 아예 작성할 필요가 없을 가능성이 높아집니다. 그래도 거의 완벽한 워크플로우를 찾는 경우가 여러 번 있겠지만 니즈에 완전히 맞게 조금 조정을 해야 합니다.

이 상황에서는 새로운 워크플로우를 작성하거나 사전에 작성된 워크플로우를 맞춤화할 수 있습니다. 또한 워크플로우를 맞춤화 하는 방법을 모르신다면 제가 정리한 이 기사를 읽어보세요.

사전에 작성된 GitHub Actions 워크플로우를 맞춤화 하는 방법을 참고하시기 바랍니다.

 

 

독자적인 GitHub 액션 워크플로우를 구축하는 방법을 학습합니다.

다른 누군가가 실시간으로 뭔가를 하는 것을 봄으로써 배우는 것이 쉬울 수 있습니다. 따라서 자체 GitHub Actions 워크플로우를 구축하고자 한다면 이 비디오를 보고 10분 이내에 자체 액션을 구축하는 방법을 학습해 주시기 바랍니다.

 

여기까지 'GitHub의 CI/CD 및 자동화 초보자 가이드 제2장'이었습니다.

유익하셨길 바라며 저희는 다음 시간에 또 다른 유익한 콘텐츠로 찾아뵙겠습니다.

감사합니다.