빌드·패키징·무결성 검증
빌드·패키징·릴리스·배포를 구분하고 의존성, 패키지 구성 및 무결성을 검증한다.
핵심 범위
제품 소프트웨어 패키징에서는 빌드 자동화 도구, 애플리케이션 패키징, 배포 도구, 모니터링 도구의 역할을 구분한다.
빌드·패키징·릴리스·배포
| 단계 | 의미 |
|---|---|
| 빌드 | 소스 코드와 의존성을 컴파일·변환하여 실행 가능한 산출물을 생성 |
| 패키징 | 실행 파일, 설정, 문서 등을 배포 가능한 단위로 구성 |
| 릴리스 | 검증된 특정 버전을 공식 배포 대상으로 승인 |
| 배포 | 승인된 패키지를 사용자 또는 운영 환경에 설치·적용 |
빌드 성공은 릴리스 승인이나 운영 배포 완료와 같은 의미가 아니다.
빌드 자동화 도구
| 도구 | 핵심 특징 |
|---|---|
| Ant | XML 기반 build.xml에서 target과 task를 정의 |
| Maven | pom.xml과 생명주기 단계에 따라 빌드·테스트·패키징 수행 |
| Gradle | task 기반으로 빌드 절차를 구성하며 Groovy 또는 Kotlin DSL 사용 |
| Jenkins | 빌드·테스트·배포 작업을 자동 실행하는 지속적 통합 도구 |
Maven의 compile·test·package·install·deploy는 역할이 다르다. package는 패키지 생성, install은 로컬 저장소 설치, deploy는 원격 아티팩트 저장소 게시이며 운영 서버 설치와 자동으로 같은 뜻이 아니다.
애플리케이션 패키징
패키지에는 다음 항목이 포함될 수 있다.
- 실행 파일과 필요한 라이브러리
- 환경별 설정을 위한 기본 파일 또는 설정 지침
- 설치·제거 스크립트
- 제품 버전과 구성 정보를 담은 매니페스트
- 설치 매뉴얼과 사용자 매뉴얼
- 변경 내용과 주의사항을 담은 릴리스 노트
운영 비밀번호, 개인키, 임시 로그, 개발용 테스트 데이터처럼 배포에 불필요하거나 민감한 자료는 포함하지 않는다.
패키징에서는 필요한 파일의 존재뿐 아니라 중복 의존성, 버전 충돌, 상대 경로와 실제 로딩 규칙도 확인한다. 매니페스트와 실행되는 구성은 일치해야 한다.
패키지 검증
- 파일 목록으로 누락 여부를 확인한다.
- 버전과 대상 환경이 맞는지 확인한다.
- 체크섬 또는 해시값으로 전송 중 파일이 변경되었는지 확인할 수 있다.
- 설치 전에 요구 운영체제, 런타임, 저장 공간과 권한을 확인한다.
체크섬은 파일 내용 변경을 확인하는 값이며, 설치 절차나 사용 권한 전체를 보장하는 것은 아니다.
배포 대상의 운영체제·CPU 구조·런타임·라이브러리 요구를 확인한다. 패키지 무결성, 기능 정확성, 플랫폼 호환성은 각각 다른 검증 항목이다.
배포 도구와 모니터링 도구
- 배포 도구는 패키지 전달, 설치, 설정 적용, 서비스 시작 등의 작업을 자동화한다.
- 모니터링 도구는 실행 상태, 자원 사용량, 응답시간, 오류 발생 여부를 확인한다.
패키징은 배포 파일을 만드는 활동이고, 모니터링은 배포 후 애플리케이션 상태를 관찰하는 활동이다.
빌드 태스크의 직접·전이 의존성
어떤 태스크가 다른 태스크에 의존하면 그 선행 작업도 실행 대상에 포함된다. 선행 작업에 다시 의존성이 있으면 끝까지 따라가며, 여러 경로로 도달한 동일 태스크는 하나로 센다. 예를 들어 P가 C와 D에, C가 R에 의존하면 P 요청의 의존성 집합은 P·C·D·R이다. P에서 도달할 수 없는 T는 자동으로 포함되지 않는다. 이것은 실행 대상의 판별이며, C와 D 사이의 순서가 별도로 정해지지 않았다면 두 태스크의 유일한 실행 순서를 단정하지 않는다. 순환 의존성은 실행 순서 결정에 문제를 일으킨다.
증분 빌드는 변경된 입력의 영향을 받는 산출물을 다시 만든다. 소스뿐 아니라 컴파일 옵션과 의존 라이브러리도 빌드 결과에 영향을 주므로, 입력이 달라졌을 때 이전 산출물을 무조건 재사용해서는 안 된다.