애저듣보잡 - Github Workflow/Actions 소개
Github Actions에 대한 좋은 동영상 강의가 있습니다. ^^
GitHub Actions로 개발 주기 자동화 | ep1. Welcome 세션 | 애저듣보잡
; https://www.youtube.com/watch?v=MhGpFunlmMQ
GitHub Actions로 개발 주기 자동화 | ep2-1. GitHub Actions 소개 | 애저듣보잡
; https://www.youtube.com/watch?v=kS3wD-QhYUs
GitHub Actions로 개발 주기 자동화 | ep2-2. GitHub Actions 소개 | 애저듣보잡
; https://www.youtube.com/watch?v=9OCy-KNetws
GitHub Actions로 개발 주기 자동화 | ep3-1. GitHub Actions 실무에 사용하기 1편: 코드, 빌드, 테스트 | 애저듣보잡
; https://www.youtube.com/watch?v=VhOKYqEzdwE
GitHub Actions로 개발 주기 자동화 | ep3-2. GitHub Actions 실무에 사용하기 1편: 코드, 빌드, 테스트 | 애저듣보잡
; https://www.youtube.com/watch?v=mipyHbipkCQ
GitHub Actions로 개발 주기 자동화 | ep4-1. GitHub Actions 실무에 사용하기 2편: 협업하기 | 애저듣보잡
; https://www.youtube.com/watch?v=UdMC_ih9N20
GitHub Actions로 개발 주기 자동화 | ep4-2. GitHub Actions 실무에 사용하기 2편: 협업하기 | 애저듣보잡
; https://www.youtube.com/watch?v=TRsgxkBW1Q0
GitHub Actions로 개발 주기 자동화 | ep4-3. GitHub Actions 실무에 사용하기 2편: 협업하기 | 애저듣보잡
; https://www.youtube.com/watch?v=7I-gpWVCMuk
GitHub Actions로 개발 주기 자동화 | ep5. 클로징| 애저듣보잡
; https://www.youtube.com/watch?v=2yrgj4xYiwU
이번 글은 위의 동영상 중 일부만 정리한 것입니다.
마침 저 역시 그냥 소스 코드만 올리고 방치하다시피 버려진(?) repo가 여럿 있는데 그 중의 하나로 github actions를 실습해 보겠습니다. ^^
https://github.com/stjeong/RefOwner/
여러분도 자신이 가지고 있는 repo에 들어가면 되는데, 그곳의 "Actions" 탭을 눌러 시작할 수 있습니다.
첫 화면을 보면, 해당 repo의 프로젝트를 기반으로 적절한 workflow 템플릿을 "Suggested"하는 목록을 보여주는데요, Github Actions를 바닥부터 만드는 지루함을 없애주므로 적절한 템플릿을 선택하면 됩니다. 위의 화면에서는 RefOwner 프로젝트가 닷넷 프로젝트이기 때문에 ".NET"과 ".NET Desktop"을 보여주고 있습니다.
".NET"은 .NET Core 프로젝트를 위한 템플릿이고, ".NET Desktop"도 .NET Core의 Desktop 프로젝트를 위한 것이므로 (.NET Framework를 대상으로 하는) RefOwner의 성격상 2가지 모두 적절하지 않습니다. 따라서, "set up a workflow yourself" 링크를 눌러 직접 구성하거나 아니면 해당 화면에서 아래로 내려 보면 "More conitnuous integration workflows..."라는 버튼을 볼 수 있으니 그것을 통해 "MSBuild based projects"를 선택하는 것도 좋겠습니다.
여기서는 "MSBuild based projects"를 선택해 "Set up this workflow" 버튼을 누릅니다. 그럼, RefOwner repo의 "/.github/workflows"에 "msbuild.yml" 파일에 대한 편집 모드로 진입합니다.
msbuild.yml 템플릿의 내용도 github에서 관리되고 있는데,
MSBuild based projects
; https://github.com/actions/starter-workflows/blob/c6c0c7b5efb8a6d4121a9e15b3007b6cc794681e/ci/msbuild.yml
(2021년 2월 18일 기준) 다음과 같은 내용의 파일입니다.
name: MSBuild
on: [push]
env:
# Path to the solution file relative to the root of the project.
SOLUTION_FILE_PATH: .
# Configuration type to build.
# You can convert this to a build matrix if you need coverage of multiple configuration types.
# https://docs.github.com/actions/learn-github-actions/managing-complex-workflows#using-a-build-matrix
BUILD_CONFIGURATION: Release
jobs:
build:
runs-on: windows-latest
steps:
- uses: actions/checkout@v2
- name: Add MSBuild to PATH
uses: microsoft/setup-msbuild@v1
- name: Restore NuGet packages
working-directory: ${{env.GITHUB_WORKSPACE}}
run: nuget restore ${{env.SOLUTION_FILE_PATH}}
- name: Build
working-directory: ${{env.GITHUB_WORKSPACE}}
# Add additional options to the MSBuild command line here (like platform or verbosity level).
# See https://docs.microsoft.com/visualstudio/msbuild/msbuild-command-line-reference
run: msbuild /m /p:Configuration=${{env.BUILD_CONFIGURATION}} ${{env.SOLUTION_FILE_PATH}}
Azure Devops를 경험하신 분은,
기존 github 프로젝트를 Azure Devops의 빌드 Pipeline에 연결하는 방법
; https://www.sysnet.pe.kr/2/0/12524
github의 yml 파일도 유사한 형식을 띠고 있다는 것을 금방 눈치채실 수 있을 것입니다. 예를 들어, "runs-on"의 "
windows-latest"는 "
기존 github 프로젝트를 Azure Devops의 빌드 Pipeline에 연결하는 방법"에서 다룬 vmImage와 동일한 것으로, 즉 "Windows Server 2019 with Visual Studio 2019" 환경을 의미합니다.
물론, 원한다면 yml 문법에 맞게 위의 내용을 변경할 수 있는데, 여기서는 실습이니 그냥 "Start commit"으로 해당 github action 스크립트를 repo에 추가하겠습니다.
여기까지 완료했으면, 이제 github 측은 추가된 yml 파일에 따라 자동으로 빌드를 시작하는데 이 상황은 해당 repo의 "Actions" 탭을 다시 방문하면 확인할 수 있습니다.
참고로, 이러한 action 스크립트는 원한다면 (위의 화면에도 볼 수 있는) "New workflow" 버튼을 이용해 추가 생성하는 것이 가능합니다. (또는 "/.github/workflows" 경로에 workflow를 담은 yml 파일을 직접 생성해도 됩니다.)
자, 이렇게 해서 빌드에 성공했으면 우리도 이제 github repo의 README.md에 빌드 상황을 나타내는 배지를 달 수 있습니다. ^^ 이를 위해 우선 빌드 상태를 대표하는 배지의 경로를 알아야 하는데 아래와 같이 "Actions" 탭에서 해당 빌드 workflow의 "..." 버튼을 눌러 "Create status badge" 메뉴를 선택하면 됩니다.
그럼 이렇게 화면이 뜨고,
제공해주는 markdown 텍스트를 여러분들의 repo에 있는 README.md의 적절한 위치에 복사합니다. 이후, repo를 방문할 때마다 다음과 같이 빌드 상태 정보를 볼 수 있는 배지가 뜨게 됩니다. ^^
이러한 배지를 (github뿐만 아니라) 다양한 소스 컨트롤 제품으로부터 구성할 수 있는 전문적인 사이트도 있습니다.
Shields IO
; https://shields.io/
Shield IO 사용법
; https://velog.io/@loakick/Shield-IO-%EC%82%AC%EC%9A%A9%EB%B2%95-iojyndy4pi
사용법도 간단하고, 만약 저 중에 없는 것이라도 정적으로 해당 문구를 배지 형식처럼 이쁘게 만들 수도 있으므로 약간의 시간만으로 자신의 README.md를 멋있게 꾸미는 것이 가능합니다. ^^
yml의 스키마 설명은 다음의 영상에서 설명하고 있습니다.
GitHub Actions로 개발 주기 자동화 | ep2-2. GitHub Actions 소개 | 애저듣보잡
; https://www.youtube.com/watch?v=9OCy-KNetws
간단하게 "Workflow -> Job -> Step -> Action"로 정리를 해주고 있는데요, yml 파일이 하나의 Workflow이고 그 안에 대표적으로 jobs / step / action 단계로 설정하는 것입니다. 이 중에서 jobs는 여러 개가 지정이 가능한데 각각의 job 하나 당 VM 빌드 이미지가 생성돼 격리된 공간에서 job에 포함된 작업들이 실행됩니다. 그리고 순서대로 처리되지 않기 때문에 그게 필요하다면 의존성을 지정해야 합니다.
참고로, workflow가 언제 구동될지는 다음의 문서에서 잘 설명하고 있습니다.
Events that trigger workflows
; https://docs.github.com/en/actions/reference/events-that-trigger-workflows
나머지 내용들은 직관적으로 알 수 있지만 그중에 잘 이해가 안 되는 것이 "steps:" 내에 속한 "uses"의 값입니다. 이에 대해서는 github가 미리 제공하는 action들로 다음의 URL에서 정의된 것들을 의미합니다.
GitHub Actions
; https://github.com/actions
예를 들어 "actions/checkout"은 "
https://github.com/actions/checkout"에 정의한 동작으로 해당 경로에 가면 checkout의 전체적인 지원 구문을 확인할 수 있습니다. 일단 저 정도만 대충 이해하면 yml 파일을 사용하는데 특별한 문제점은 없을 것입니다.
여기까지 배운 지식을 기반으로 현재 RefOwner에 기본 생성한 msbuild.yml에 변경하면 좋을 점이 있다면 아마도 workflow를 구동하는 조건을 단순히 모든 push에 반응하기보다는 master 브랜치로 한정하는 식으로 변경하는 정도가 될 듯합니다. ^^
name: MSBuild
on:
push:
branches:
- master
pull_request:
branches:
- master
...[생략]...
재미있는 것은, 이러한 workflow가 단순히 빌드에만 사용되는 것은 아니라는 점입니다. 가령, issue의 평가를 분류하는 데도 사용할 수 있고 특정 평가가 내려지면 이슈를 닫는 것도 가능합니다. 실제로, 여러분이 간혹 잘 조직된 repo에 이슈를 남기는 경우 다음과 같이 다양한 라벨링이나 "dotnet-bot" 등의 대응을 볼 수 있는데요,
이런 것들이 모두 workflow 제작으로 가능한데, 위에서 소개한 동영상의 ep4에 해당하는 것들이 모두 그런 방법들을 다루고 있습니다.
GitHub Actions로 개발 주기 자동화 | ep4-1. GitHub Actions 실무에 사용하기 2편: 협업하기 | 애저듣보잡
; https://www.youtube.com/watch?v=UdMC_ih9N20
GitHub Actions로 개발 주기 자동화 | ep4-2. GitHub Actions 실무에 사용하기 2편: 협업하기 | 애저듣보잡
; https://www.youtube.com/watch?v=TRsgxkBW1Q0
GitHub Actions로 개발 주기 자동화 | ep4-3. GitHub Actions 실무에 사용하기 2편: 협업하기 | 애저듣보잡
; https://www.youtube.com/watch?v=7I-gpWVCMuk
이 외에 좀 더 고급진 활용 방안을 다음의 문서에서 확인할 수 있습니다.
Learning Lab - Advance your journey
; https://lab.github.com/
github actions의 이러한 활용은, "
기존 github 프로젝트를 Azure Devops의 빌드 Pipeline에 연결하는 방법"의 Azure Devops의 빌드 파이프라인의 사용을 무색게 합니다.
저렇게만 놓고 봤을 때, 사실 github를 대상으로 한다면 굳이 Azure Devops의 빌드를 사용하기보다 github의 빌드 workflow가 더 낫습니다. 물론, github는 하나의 형상 관리 제품인 반면 Azure Devops는 단독으로도 형상 관리 제품이면서 동시에 다른 형상 관리 제품에 대한 Azure Devops의 기능을 제공한다는 차이점이 있습니다.
참고로, 아래의 글에서는 .NET Framework를 위한 GitHub actions를 직접 만드는 방법을 소개하고 있는데,
GitHub Actions for .NET Framework
; https://dev.to/n3wt0n/github-actions-for-net-framework-1pk4
위의 글에 실린 동영상 강의에 나온 템플릿이 현재 github 측에서 제공하는 "MSBuild based projects" 템플릿과 거의 유사합니다.
마지막으로 미세한 팁 하나를 소개하면, 개인적으로 2가지 CD에 대해 별로 궁금함이 없었는데 ep2-1 영상에서 다음과 같이 설명하고 있어서 알게 되었습니다. ^^
Continuous Delivery
- 개발 환경까지 자동화, 운영 환경까지의 배포는 별도의 트리거로 분리
Continuous Deployment
- 개발 환경 및 운영 환경까지 자동화
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]