Daily Build and Smoke Test
스티브 맥코널은 1996 년 IEEE Software "Daily Build and Smoke Test" 컬럼에서 Microsoft와 일부 다른 소프트웨어 회사에서는 "Daily Build and Smoke Test" 프로세스가 일반적이라고 기술하고 있다. (다른 세상이야기 같이 느끼고 있다면 당장 변화가 필요하다.)
하나의 파일로 구성된 간단한 프로그램을 만들려면 그 하나의 파일을 컴파일하고 링크하기만 하면 된다. 하지만 수십, 수백, 수천 개의 파일이 포함된 팀 프로젝트에서는 (이는 다양한 구성 요소로 프로그램을 '빌드'해야 하기 때문에) 실행 가능한 프로그램을 만드는 과정은 더 복잡하고 많은 시간이 소요된다.
"Daily Build and Smoke Test" 프로세스는 간단하게 매일 매일 빌드하고 매일 테스트하는 것을 의미한다.
Daily Build(이하 일일 빌드)에서 기본은 '매일'이라는 것이다. 짐 맥카시 말처럼 (Dynamics of Software Development, Microsoft Press, 1995), 일일 빌드는 프로젝트의 심장박동이고, 심장박동이 없는 프로젝트는 죽은 것 이다.
Smoke Test (이하 스모크 테스트) 는 새로운 빌드 또는 릴리스 후 시스템의 가장 중요한 기능이 예상대로 작동하는지 신속하게 확인하기 위해 수행하는 소프트웨어 테스트의 한 유형이다.
스모크 테스트'라는 용어는 하드웨어 테스트 업계에서 유래한 것으로, 기술자가 새 기기를 켜서 연기가 나기 시작하면 하드웨어에 심각한 문제가 있음을 나타낸다. 마찬가지로 소프트웨어 개발에서 스모크 테스트는 일반적으로 애플리케이션 또는 시스템을 시작할 수 있는지, 주요 기능이 올바르게 작동하는지, 주요 문제나 심각한 버그가 없는지 확인하기 위해 실행되는 일련의 기본 테스트이다. 스모크 테스트는 자동화되는 경우가 많으며 일반적으로 개발 주기 초기에 문제를 파악하기 위해 각 빌드 후에 실행된다.
컬럼이 1996 년도 에 작성된 것을 고려하면 아직 많은 소프트웨어 개발 현장에서 적용되지 않고 있는 것에 많은 아쉬움이 있다.
◼︎ 이점
이 간단한 프로세스는 몇 가지 중요한 이점을 제공한다.
- 통합 위험을 최소화 : 팀 프로젝트가 직면하는 가장 큰 위험 중 하나는 여러 팀원이 개별적으로 작업하던 코드를 결합하거나 '통합'할 때 그 결과물인 복합 코드가 제대로 작동하지 않는다는 것이다. 프로젝트 후반에 비호환성이 발견되면 통합이 더 일찍 이루어졌을 때보다 디버깅 시간이 더 오래 걸리거나, 프로그램 인터페이스를 변경해야 하거나, 시스템의 주요 부분을 다시 설계하고 다시 구현해야 할 수도 있다. 극단적인 경우에는 통합 오류로 인해 프로젝트가 취소되는 경우도 있다. 일일 빌드 및 스모크 테스트 프로세스는 통합 오류를 작고 관리하기 쉬운 수준으로 유지하며 통합 문제가 발생하는 것을 방지한다.
- 품질 저하 위험을 최소화 : 통합에 실패하거나 문제가 발생할 위험과 관련하여 품질 저하가 발생할 위험이 있다. 매일 모든 코드를 최소한의 스모크 테스트로 테스트하면 품질 문제로 인해 프로젝트가 중단되는 것을 방지할 수 있다.
- 더 쉬운 결함 진단을 지원 : 매일 제품을 빌드하고 테스트하면 특정 날짜에 제품이 고장난 이유를 쉽게 파악할 수 있다. 17일째에는 작동하던 제품이 18일째에 고장난 경우, 두 빌드 사이에 어떤 일이 발생하여 제품이 고장난 것으로 추정할 수 있다.
- 팀 사기 향상 : 제품이 작동하는 것을 보면 사기가 엄청나게 높아진다. 제품이 어떤 기능을 하는지는 거의 중요하지 않는다. 개발자는 사각형이 표시되는 것을 보는 것만으로도 흥분할 수 있다! 일일 빌드를 사용하면 매일 조금씩 더 많은 제품이 작동하므로 사기가 높아질 것 이다.
Daily Build and Smoke Test 프로세스 자동화
◼︎ 환경
- Model : MacBook Pro (14-inch, 2021)
- CPU : Apple M1 Pro
- MENORY : 16GB
- DISK : 512 GB SSD
- OS : macOS 13.2.1 (22D68)
- TOOLS : Visual Studio Code, Java 11, Gradle
- Version Control : GitHub
- Programming Language : Java
Daily Build adn Smoke Test 프로세스의 기본 아이디어는 단순히 제품을 빌드하고 매일 테스트하는 것이다. GitHub 을 사용하고 있다면 GitHub Actions 을 사용하여 아주 쉽게 프로세스를 자동화 할 수 있다.
 |
| Source – https://docs.github.com/en/actions |
GitHub Actions 는 리포지토리의 워크플로우를 자동화하는 GitHub에서 제공하는 지속적인 통합 및 배포(CI/CD) 서비스이다. 이를 통해 개발자는 사용자 지정 워크플로를 GitHub 리포지토리에서 직접 빌드, 테스트 및 배포와 같은 다양한 작업을 자동화할 수 있으며 아래와 같은 특징을 가지고 있다.
- YAML (YAML Ain't Markup Language) 파일을 사용 테스트 실행, Docker 이미지 빌드, 서버에 코드 배포 등 .. 실행할 작업의 순서를 지정하는 워크플로우를 정의한다.
- Pull Requests, 커밋 또는 릴리즈와 같은 다양한 이벤트에 의해 동작이 시작될 수 있으며, Linux, Windows 또는 macOS와 같은 다양한 운영 체제에서 실행할 수 있다.
- 워크플로에서 바로 사용이 가능한 AWS, Google Cloud 또는 Slack 등 타사 도구 및 서비스와의 통합도 지원한다.
- 워크플로는 GitHub가 제공하는 Linux, Windows 및 macOS 등 가상 머신에서 실행하거나 자체 데이터 센터 또는 클라우드 인프라에서 호스팅 러너를 설치하여 사용할 수 있다.
Gradle 을 사용하는 Java 스프링 부트 프로젝트를 자동으로 빌드하고 테스트하는 경우를 생각해보자.
① 프로젝트 레파지토리에서 .github/workflows/gradle.yml 워크플로우 파일 생성.직접 파일을 만들어도 되지만 GitHub 에서 제공하는 기능을 사용하면 몇번의 클릭 만으로 생성할 수 있다.
⑴ GitHub 프로젝트 레파지토리 > Actions 탭 > New workflow 버튼 클릭
⑶ 워크플로우 수정 및 커밋
기본적으로 대부분의 기능이 포함되어 구성되기 때문에 몇가지 만 확인하고 바로 커밋하면 된다.
Customizing when workflow runs are triggered
on:
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]
Daily Build 에 맞게 매일 오후 5시에 주기적으로 실행되게 하려면 아래와 같이 schedule 옵션을 사용 cron 표현식을 사용하여 일정을 지정하면 된다.
워크플로우 작업을 실행할 러너 지정할 수 있는데 github 에서 제공하는 다양한 가상머신 기반의 러너를 사용하거나 아니면 직접 러너를 설치하여 사용할 수 있다.
on:
schedule:
- cron: '0 17 * * *'
Running your jobs on different operating systems
최신 맥 가상머신에서 실행하는 것으로 지정하였다. 참고로 private 레파지토리는 사용량에 따라 무료 제공되는 2,000 분을 초과하면 과금이 발생된다.
jobs:
build:
runs-on: macos-latest
- Red Hat Enterprise Linux 7 or later
- CentOS 7 or later
- Oracle Linux 7 or later
- Fedora 29 or later
- Debian 9 or later
- Ubuntu 16.04 or later
- Linux Mint 18 or later
- openSUSE 15 or later
- SUSE Enterprise Linux (SLES) 12 SP2 or later
- Windows 7 64-bit
- Windows 8.1 64-bit
- Windows 10 64-bit
- Windows Server 2012 R2 64-bit
- Windows Server 2016 64-bit
- Windows Server 2019 64-bit
- Windows Server 2022 64-bit
- macOSmacOS 10.13 (High Sierra) or later
- x64 - Linux, macOS, Windows.
- ARM64 - Linux, macOS, Windows (currently in beta).
- ARM32 - Linux.
레파지토리, 조직 또는 엔터프라이즈에 자체 호스팅 러너를 추가할 수 있다. 레파지토리 러너 추가는 아래와 같은 절차로 진행한다.
❶ 레파지토리 메인 > 세팅 탭 > 좌측 메뉴에서 runners 선택
❷ New self-hosted runner 버튼 클릭
❸ 러너 이미지와 아키텍처를 선택하고 안내에 따라 해당 호스트에서 러너를 설치하고 실행한다.
(참고로 장비는 오라클 클라우드에서 무료로 제공하는 VM 인스턴스를 사용하였다. )
 |
| 라벨명 'self-hosted-oracle' 으로 등록 |
❹ 마지막으로 편의를 위하여 서비스로 설치하고 실행한다.
➜ Configuring the self-hosted runner application as a service
[opc@instance-****-**** actions-runner]$ sudo ./svc.sh install
...
[opc@instance-****-**** actions-runner]$ sudo ./svc.sh start
❺ 레파지토리 메인 > 세팅 탭 > 좌측 메뉴에서 runners 선택하면 추가된 러너를 확인 할 수 있다.
❻ 추가된 러너로 워크플로우를 실행하기 위하여 프로젝트 레파지토리 .github/workflows/gradle.yml 파일을 아래와 같이 수정하고 start commit 하면 워크플로우가 등록한 러너에서 실행된다.
jobs:
build:
runs-on: self-hosted
GitHub 제공 러너, Mac Mini 에 설치한 러너, Oracle Cloud VM 에 설치한 러너 에서 각각 실행한 결과 GitHub 제공 러너 (1m42s), 맥미니 호스트 러너(4m32s ), Oracle Cloud VM 호스트 러너(23m51s) 순으로 실행 속도가 나타났다.
주의할 점은 GitHub Actions 이 14일 동안 실행되지 않으면 GitHub 에서 자동 삭제된다.
⑷ 워크플로우 상태 노출 하기
마지막 워크플로우 실행 결과를 레파지토리 README 파일을 수정하여 노출할 수 있는데 이를 통하여 마지막 빌드 결과를 확인하고 바로 조치할 수 있다.
❶ 레파지토리 메인 > Actions 탭 > 좌측 메뉴에서 앞서 등록한 Java CI with Gradle 선택
❷ Java CI with Gradle 워크플로우 실행 결과 상세 이동
❸ Create status badge 클릭 생성된 markdown 텍스트를 복사하고 README.md 파일에 내용을 추가한다.
❹ 이제부터 레파지토리 메인 에서 항상 빌드 결과를 확인할 수 있다.
댓글 없음:
댓글 쓰기