버전 관리 & Build

독립적인 버전 관리

Lino 프로젝트에는 여러 서비스와 웹 애플리케이션이 포함될 수 있습니다. 각 배포 가능한 항목은 자체 버전을 가지므로, 한 서비스의 작은 수정이 전체 시스템의 인위적인 release를 강제하지 않습니다. 이는 API, workers, web apps, migrations, 통합 계약이 서로 다른 속도로 발전할 수 있는 모듈형 및 분산 아키텍처에서 중요합니다.

운영 버전은 version.txt라는 단순한 텍스트 파일에 저장됩니다. 서비스의 경우 파일은 src/Services/<ServiceName>/version.txt에 있습니다. 웹 애플리케이션의 경우 src/WebApps/<WebAppName>/version.txt에 있습니다. Lino CLI는 버전 목록 조회, 확인, 증가, 버전이 지정된 build 생성 시 이 파일들을 읽습니다.

Lino가 사용하는 SemVer 규칙

MAJOR.MINOR.PATCH

• PATCH는 마지막 숫자를 증가시키며, 호환 가능한 수정, 작은 내부 개선, 공개 contract를 변경하지 않는 변경에 사용해야 합니다.
• MINOR는 가운데 숫자를 증가시키고 patch를 0으로 재설정합니다. 하위 호환 기능, 새 endpoints, 선택적 필드 또는 추가적 동작에 사용합니다.
• MAJOR는 첫 번째 숫자를 증가시키고 minor와 patch를 0으로 재설정합니다. API contract가 호환되지 않게 변경되었거나 동작이 의도적으로 대체되어 소비자가 적응해야 할 때 사용합니다.

예: 1.0.0은 첫 안정 버전, 1.0.1은 호환 가능한 수정, 1.1.0은 호환 가능한 새 기능 또는 breaking change 없는 새 endpoints, 2.0.0은 클라이언트 업데이트가 필요한 변경을 포함한 release를 나타낼 수 있습니다.

현재 버전 확인

프로젝트의 모든 서비스와 웹 애플리케이션의 현재 버전을 보려면 lino version list를 사용합니다:

lino version list

특정 서비스 또는 웹 애플리케이션의 버전을 확인해야 할 때는 lino version show를 사용합니다. 이 명령은 대상이 서비스인지 웹 애플리케이션인지 묻고, 해당 version.txt 파일에서 읽은 버전을 표시합니다.

lino version show

버전 증가

서비스 또는 웹 애플리케이션이 새 release 준비가 되었을 때 lino version bump를 사용합니다:

lino version bump

1. 프로젝트 루트에서 명령을 실행합니다.
2. 하나 이상의 서비스 또는 웹 애플리케이션을 선택합니다. 프롬프트는 각 항목과 현재 버전을 보여 줍니다.
3. 증가 유형을 선택합니다: patch, minor 또는 major.
4. 응답을 확인합니다. Lino는 선택된 version.txt 파일을 업데이트하고 새 버전이 포함된 표를 표시합니다.

각 실행은 명확한 변경 추적을 유지하고 release 관행과의 일관성을 높이며 CI/CD pipelines와의 정렬을 쉽게 합니다. 버전 번호는 더 이상 떨어져 있는 세부 정보가 아니라 실제로 변경된 배포 가능한 아티팩트를 식별합니다.

버전 변경은 release의 기술적 영향과 함께 검토해야 합니다. 데이터베이스 migration이 서비스 버전에 연결될 수 있고, API 소비자는 contract notes가 필요할 수 있으며, 통합 이벤트는 호환성 검사를 요구할 수 있습니다. 버전을 배포 가능한 항목 가까이에 두면 이러한 결정이 명확해지고 감사하기 쉬워집니다.

major 증가 전에는 공개 API, 이벤트 contract, migrations, 클라이언트 호환성, 외부 소비자를 검토합니다. minor 증가 전에는 새 동작이 추가적임을 확인합니다. patch 전에는 변경이 호환 가능하고 사용 기대를 바꾸지 않는지 확인합니다.

Build와 컨테이너화

동영상과 일상 개발에서는 각 모델링 단계 후 생성된 솔루션이 여전히 컴파일되는지 검증하기 위해 dotnet build를 자주 사용합니다. lino build 명령의 목적은 다릅니다. 선택한 서비스와 웹 애플리케이션을 .NET container publish profile로 Release 모드에서 게시하여 release 준비를 합니다.

이 분리는 단순한 컴파일 검증을 전달 패키지로 취급하지 않게 합니다. 개발 중에는 오류를 빨리 찾기 위해 dotnet build를 사용합니다. 아티팩트가 버전을 받고 container image가 되어 registry 또는 deploy pipeline으로 이동할 준비가 되었을 때 lino build를 사용합니다.

lino build가 하는 일

Lino 프로젝트 루트에서 명령을 실행합니다:

lino build

CLI는 인증된 사용자와 현재 프로젝트 구성을 검증하고, 어떤 서비스 또는 웹 애플리케이션을 build에 포함할지 묻고, 이어서 버전을 유지할지 증가시킬지 묻습니다. 증가가 선택되면 Lino는 build 명령을 생성하기 전에 해당 version.txt를 업데이트합니다.

backend는 실행할 정확한 명령을 반환합니다. 현재 이 명령들은 dotnet publish와 -c Release, -p:PublishProfile=DefaultContainer, -p:ContainerRepository, -p:ContainerImageTag, -p:ContainerLabelVersion를 사용합니다. image tag와 container version label은 release에 선택된 동일한 SemVer 값을 받습니다.

실제로 이 프로세스는 서비스 또는 웹 애플리케이션 코드를 컴파일하고, 필요한 게시 구성을 적용하며, 현재 SemVer 버전을 기반으로 container image를 생성하고, 아티팩트에 표준화된 이름, tag, metadata를 부여합니다.

생성되는 repository 이름

Lino는 예측 가능한 container repository를 생성하기 위해 프로젝트와 항목 이름을 정규화합니다:

• 단순 서비스 API: <project-name>/services/<service-name>-api:1.2.3
• 모듈형 서비스 host: <project-name>/services/<service-name>-host:1.2.3
• Blazor 웹 애플리케이션: <project-name>/webapps/<webapp-name>:1.2.3

이 규칙은 서비스 API, 모듈형 hosts, 웹 애플리케이션을 registry에서 분리하고 release 버전을 tag에 보존합니다. 또한 반복적인 수동 결정을 제거하고 환경, CI/CD scripts, 운영 문서 간 차이를 줄입니다.

Registries에 게시

생성된 images는 deploy 플랫폼에서 사용하는 registry에 게시할 수 있습니다:

• Docker Hub
• GitHub Container Registry
• AWS ECR
• Azure Container Registry
• 기타 OCI 호환 registry.

가능하면 floating tags 대신 1.2.3 같은 변경 불가능한 version tag를 가리켜 deploy합니다. 이렇게 하면 rollback, 감사, build·게시·배포된 내용의 비교가 개선됩니다.

권장 release 흐름

1. 패키징 전에 프로젝트 테스트와 dotnet build를 실행하여 소스 코드를 검증합니다.
2. lino version list로 현재 버전을 확인하고 어떤 서비스 또는 웹 애플리케이션이 변경되었는지 검토합니다.
3. lino build를 사용하고 현재 버전을 유지할지 patch, minor 또는 major 증가를 적용할지 선택합니다.
4. 생성된 container images를 Docker Hub, GitHub Container Registry, AWS ECR, Azure Container Registry 또는 다른 호환 registry처럼 deploy 플랫폼이 사용하는 registry에 게시합니다.
5. 추적 가능한 version tag를 참조하여 deploy하고 changelog, migrations, rollback plan을 같은 release에 연결합니다.

secrets, production connection strings, 환경별 자격 증명을 생성된 images 안에 넣지 마세요. 환경 변수, 로컬 개발용 user secrets, CI/CD secret vault 또는 deploy 플랫폼의 secret 메커니즘을 사용하세요.

이 흐름에서는 버전 관리와 build가 연결됩니다. 프로젝트에 기록된 동일한 SemVer 값이 container tag와 release metadata로 사용되어 소스 코드, migrations, API contracts, 통합 이벤트, 배포된 아티팩트 사이의 추적 가능성이 향상됩니다.