분기 및 일정과의 지속적인 통합
"가지를 사용하십시오"라고 그들은 말했습니다. "재미있을거야"라고 그들은 말했다.
응. 그러나 이 멋진 100% 버그 없는 기능을 배포하기 위해 스테이징 또는 마스터 분기에 먼저 분기를 병합하지 않고 이러한 분기를 빌드하고 테스트 서버에 배포하는 것은 어떻습니까?
음, GitLab과 약간의 YML 파일 덕분에 쉽습니다.
그건 그렇고, 이것이 GitHub , Bitbucket 등과 매우 유사하게 작동한다고 확신합니다. 우리는 사무실에서 GitLab을 사용하고 있을 뿐이므로 GitLab 솔루션을 소개합니다.
본질적으로 CI 솔루션 내에서 지속적 통합 파이프라인 또는 작업을 시작하는 방법을 먼저 파악해야 합니다.
GitLab에서
.gitlab-ci.yml
파일을 생성하고 이를 리포지토리의 루트 디렉터리(아마도 .gitignore
옆)에 넣습니다.필요한 스크립트는 배치 파일에 넣는 것과 매우 유사합니다.
JavaScript 프로젝트를 만들고 싶습니까? 아마도
npm install
를 먼저 실행하십시오..NET Core에서 무언가를 구축하시겠습니까?
dotnet restore
를 실행한 다음 dotnet publish -c Debug
를 실행합니다.다음은 .NET Core 프로젝트에 대한 간단한 예입니다.
stages:
- deploy
deploy:dev:
stage: deploy
script:
- "dotnet restore"
- echo Build Debug
- "dotnet publish -c Debug"
- echo Deploy to your dev-machine
- '"C:/Program Files (x86)/IIS/Microsoft Web Deploy V3/msdeploy.exe" ...
이 예에서
stages
는 이 스크립트에서 예상되는 단계의 종류를 알려줍니다. 모든 단계가 특정 작업이라고 말할 수도 있습니다. 그런 다음 deploy:dev
는 후속 부분의 임의 이름입니다.거기에서 현재
stage
를 설정한 다음 script
를 씁니다. 보시다시피 스크립트에는 배치 파일에서 실행하거나 Visual Studio Code의 터미널에 수동으로 입력하는 명령이 포함되어 있습니다.이것이 가장 어려운 부분입니다. 선택한 기술로 애플리케이션을 빌드하고 배포하기 위한 올바른 명령을 찾습니다.
쉬운 부분은 현재 분기에 따라 다르게 동작하는 스크립트를 빌드하는 것입니다.
다음 줄을 추가해 보겠습니다.
rules:
- if: $CI_COMMIT_REF_NAME == "dev"
전체 스크립트는 다음과 같습니다.
stages:
- deploy
deploy:dev:
rules:
- if: $CI_COMMIT_REF_NAME == "dev"
stage: deploy
script:
- "dotnet restore"
- echo Build Debug
- "dotnet publish -c Debug"
- echo Deploy to your dev-machine
- '"C:/Program Files (x86)/IIS/Microsoft Web Deploy V3/msdeploy.exe" ...
rules
를 사용하면 스크립트를 실행할 시기를 정의할 수 있습니다. 이 특별한 경우 코드 변경 사항을 dev 브랜치에 커밋한 경우에만 실행됩니다.이제 큰 문제는 다른 지점은 어떻게 됩니까?
분기마다 다른 YML 파일이 필요합니까? 그리고 이러한 분기를 병합할 때 주의해야 합니까?
그리고 우리 모두가 알다시피, 주의를 기울이는 것은 결국 비극적으로 끝납니다.
다행히도 이것은 과거의 문제입니다.
다른 분기에 대한 스크립트를 동일한 파일에 추가하기만 하면 됩니다.
stages:
- .pre
- deploy
build:master:
rules:
- if: $CI_COMMIT_REF_NAME == "master"
stage: .pre
script:
- "dotnet restore"
- echo Build Debug
- "dotnet publish -c Debug"
deploy:dev:
rules:
- if: $CI_COMMIT_REF_NAME == "dev"
stage: deploy
script:
- "dotnet restore"
- echo Build Debug
- "dotnet publish -c Debug"
- echo Deploy to your dev-machine
- '"C:/Program Files (x86)/IIS/Microsoft Web Deploy V3/msdeploy.exe" ...
위의 예에서 변경 사항이 마스터 브랜치에 커밋된 경우에만 애플리케이션이 빌드됩니다.
하지만 마스터 브랜치를 자동으로 배포하고 싶을 수도 있습니다. 모든 커밋이 아니라 매일 밤 또는 매주?
이 경우 스케줄러를 구성한 다음 스케줄러가 작업을 시작할 때만 호출되어야 하는 다른 스크립트를 추가합니다.
GitLab에서 일정은 다음과 같이 표시됩니다.
변수
CI_PIPELINE_SOURCE
를 정의하고 값을 schedules
로 설정합니다. 그런 다음 적절한 스크립트에서 이 변수를 사용할 수 있습니다.stages:
- .pre
- deploy
build:master:
rules:
- if: $CI_COMMIT_REF_NAME == "master" && $CI_PIPELINE_SOURCE != "schedules"
stage: .pre
script:
- "dotnet restore"
- echo Build Debug
- "dotnet publish -c Debug"
deploy:master:
rules:
- if: $CI_COMMIT_REF_NAME == "master" && $CI_PIPELINE_SOURCE == "schedules"
stage: deploy
script:
- "dotnet restore"
- echo Build Debug
- "dotnet publish -c Debug"
- echo Deploy to your production machine
- '"C:/Program Files (x86)/IIS/Microsoft Web Deploy V3/msdeploy.exe" ...
deploy:dev:
rules:
- if: $CI_COMMIT_REF_NAME == "dev"
stage: deploy
script:
- "dotnet restore"
- echo Build Debug
- "dotnet publish -c Debug"
- echo Deploy to your dev-machine
- '"C:/Program Files (x86)/IIS/Microsoft Web Deploy V3/msdeploy.exe" ...
$CI_PIPELINE_SOURCE == "schedules"
를 사용하면 작업이 스케줄러에 의해 시작되었음을 알 수 있습니다. 그리고 이 스케줄러는 아마도 오전 3시에 실행될 것이기 때문에 우리는 동료들의 흐름을 방해하지 않고 침착하게 빌드를 프로덕션에 배포할 수 있습니다.이제 전문가들이 나에게 소리치기 전에. 이 스크립트가 완벽하지 않다는 것을 알고 있습니다.
.pre
단계 또는 예제 스크립트에서 작업을 연결하지 않는 이유와 같이 설명할 세부 정보가 있습니다. 알아, 알아, 알아!이것은 구성 방법에 대한 아이디어를 제공합니다. 자세한 내용은 official documentation 플랫폼의 DevOps을 참조하십시오. 고맙습니다.
괜찮은. 이것이 도움이 되었기를 바라며 마침내 두려움 없이 분기를 병합할 수 있습니다.
즐거운 코딩하세요!
freepik.com에서 katemangostar가 만든 이미지입니다.
하지만 더 있습니다!
Reference
이 문제에 관하여(분기 및 일정과의 지속적인 통합), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://dev.to/_patrickgod/continuous-integration-with-branches-schedules-472d텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)