아티클
튜토리얼
대화형 가이드
Bitbucket Pipelines를 통한 지속적 배포에 대해 알아보기
Sten Pittet
기고 작가
이 가이드에서는 Bitbucket Pipelines를 사용하여 지속적 배포 워크플로를 채택하는 방법을 살펴보겠습니다. 계속 읽어보세요.
시간
30분
대상 그룹
지속적 배포 및/또는 Bitbucket Pipelines를 처음 사용하는 사용자입니다.
새로운 기능을 릴리스할 때는 고객에게 새로운 기능을 제공하게 되므로 항상 흥미로운 순간입니다. 그러나 준비가 많이 필요한 위험한 작업이 될 수도 있으므로 팀이 잦은 릴리스를 꺼릴 수도 있습니다. 기다리는 시간이 길수록 프로덕션에 배포하기가 더 어려워집니다. 변경 사항이 쌓이고 변경 사항의 범위를 이해하기 어렵게 되며, 프로덕션에서 문제가 발생하면 근본 원인을 파악하기 힘듭니다.
소프트웨어 배포에 대한 두려움을 없애고 비용을 낮추는 간단한 방법은 소프트웨어를 자동화하고 작은 변경 사항을 더 자주 릴리스하는 것입니다. 우선 일반적으로 릴리스를 준비하는 데 걸리는 긴 시간을 절약할 수 있습니다. 각 릴리스의 범위가 훨씬 작아져서 소프트웨어 배포의 위험 역시 줄어들게 되므로 환경을 모니터링하고 문제를 해결하기가 쉬워집니다.
이런 배포 자동화는 지금은 Bitbucket Cloud를 통해 쉽게 할 수 있는 작업입니다. 각 리포지토리에 대해, 푸시할 때마다 코드를 자동으로 빌드, 테스트 및 환경에 배포하는 파이프라인을 구성할 수 있습니다. 이 가이드에서는 Bitbucket Pipelines를 사용하여 지속적 제공 워크플로를 채택하는 방법을 살펴보겠습니다.
지속적 제공 및 지속적 배포 비교
지속적 제공은 모든 변경 사항을 프로덕션에 배포하지 않더라도 코드를 항상 릴리스할 준비가 되었는지 확인하는 것입니다. 가능한 한 자주 프로덕션을 업데이트하여 변경 사항의 범위를 작게 유지하는 것이 좋지만 결국 릴리스의 리듬을 제어하는 것은 사용자입니다.
지속적 배포에서 리포지토리에 푸시된 새 변경 사항은 테스트를 통과하면 자동으로 프로덕션에 배포됩니다. 이것은 테스트 문화를 더 강조(또는 압박)하지만 고객과의 피드백 루프를 가속화하는 좋은 방법입니다.
지속적 제공 파이프라인 채택
이 예시에서는 빌드가 테스트를 통과하면 스테이징에 자동으로 배포하는 지속적 제공 파이프라인을 추가하여 지속적 통합 자습서에서 구축한 간단한 node.js 앱을 확장합니다. 프로덕션 배포에 대한 두 가지 전략을 살펴보겠습니다. 하나는 브랜치 및 풀리퀘스트를 사용하며 다른 하나는 사용자 지정 파이프라인 및 수동 트리거를 사용합니다.
두 예시 모두에서 브라우저에 "Hello World"라는 메시지를 표시하는 간단한 Node.js 애플리케이션을 사용합니다. 두 가지 방법을 모두 사용하여 Heroku에서 호스팅되는 스테이징 및 프로덕션 환경에 이 애플리케이션을 배포할 것입니다.
가장 기본적인 Hello World 애플리케이션
{
"name": "cdtutorial",
"version": "1.0.0",
"description": "",
"main": "server.js",
"scripts": {
"start": "node server.js",
"test": "mocha --exit"
},
"repository": {
"type": "git",
"url": "git+ssh://git@bitbucket.org/pmmquickstartguides01/cdtutorial.git"
},
"author": "",
"license": "ISC",
"bugs": {
"url": "https://bitbucket.org/pmmquickstartguides01/cdtutorial/issues"
},
"homepage": "https://bitbucket.org/pmmquickstartguides01/cdtutorial#readme",
"dependencies": {
"express": "^4.17.3"
},
"devDependencies": {
"mocha": "^9.2.2",
"supertest": "^6.2.2"
}
}server.js 파일을 다음과 같이 업데이트합니다.
var express = require("express");
var app = express();
app.get("/", function (req, res) {
res.send("Hello World!");
});
app.listen(process.env.PORT || 3000, function () {
console.log("Example app listening on port 3000!");
});
module.exports = app;app.listen()의 변경 사항을 주의하여 보세요. 여기에 이제 Heroku에서 설정한 process.env.PORT가 포함됩니다.
다음을 실행하여 예시 리포지토리의 루트 디렉터리에 Procfile을 추가합니다.
touch Procfile다음과 같은 텍스트를 Procfile에 추가합니다.
web: npm startHeroku에 로그인하여 오른쪽 상단에 있는 사용자 아이콘을 클릭하고 계정 설정을 클릭한 다음 아래로 스크롤하여 API 키를 찾습니다.
다음으로, Heroku에 배포할 수 있도록 Bitbucket Pipelines에 환경 변수를 추가합니다.
- HEROKU_API_KEY: API 키는 Heroku 계정에서 찾을 수 있습니다
리포지토리 설정에서 파이프라인 > 환경 변수로 이동하여 이 변수를 추가합니다.
Heroku에 배포할 환경 변수 설정
이 가이드에서는 Heroku를 사용하고 있으며, 이 예시는 다른 호스팅 서비스에도 적용할 수 있습니다. 이 가이드를 Heroku 참고 자료로 사용하세요.
브랜치를 프로덕션의 게이트로 사용하는 지속적 배포
이 구성은 배포에 매핑할 수 있는 특수 릴리스 브랜치가 있는 팀에 적합합니다. 또한 풀리퀘스트에서의 변경 사항을 프로덕션에 배포하기 전에 검토할 수 있습니다.
이 설정에서는 다음과 같이 서로 다른 두 브랜치를 사용하여 배포를 트리거합니다.
- main: main으로 푸시할 때마다 테스트 실행 후 스테이징 환경에 코드가 배포됩니다.
- production: production 브랜치에 병합된 코드는 자동으로 프로덕션 환경으로 릴리스됩니다.
브랜치를 클릭하여 Bitbucket Cloud에서 프로덕션 브랜치를 만듭니다
그런 다음 브랜치 만들기를 클릭합니다
production을 입력하고 만들기를 클릭합니다.
예시 리포지토리의 루트 디렉터리에서 다음을 실행합니다.
heroku create --remote staging
git push staging main
heroku create --remote production
git push production main제대로 작동하는지 확인하려면 브라우저에서 Heroku로 이동하여 두 개의 앱이 있는지 확인하세요.
다음을 실행합니다.
git remote -vv예상되는 결과에는 세 개의 remote가 있으며 하나는 Bitbucket용이고 두 개는 Heroku용입니다. 하나는 스테이징 remote, 다른 하나는 프로덕션 remote입니다.
wmarusiak@C02F207NML7L cdTutorial % git remote -vv
origin git@bitbucket.org:pmmquickstartguides01/cdtutorial.git (fetch)
origin git@bitbucket.org:pmmquickstartguides01/cdtutorial.git (push)
production https://git.heroku.com/young-harbor-11356.git (fetch)
production https://git.heroku.com/young-harbor-11356.git (push)
staging https://git.heroku.com/boiling-refuge-14681.git (fetch)
staging https://git.heroku.com/boiling-refuge-14681.git (push)그런 다음 스테이징에 대한 배포를 구성합니다. 이것을 위해 브랜치별 파이프라인을 사용하고 main 브랜치의 모든 푸시에 대해 실행되는 파이프라인을 만듭니다. 터미널에서 이 변경을 수행하고 원래 main으로 푸시합니다.
bitbucket-pipelines.yml
image: node:16
clone:
depth: full
pipelines:
branches:
main:
- step:
name: deploy_to_staging
script:
- npm install
- npm test
- git push https://heroku:$HEROKU_API_KEY@git.heroku.com/boiling-refuge-1468.git mainmain에 대한 git 푸시 URL을 위에 있는 git remote -vv의 스테이징 URL로 바꿔야 합니다.
이제 애플리케이션을 빌드 및 테스트한 후 main에서의 모든 푸시를 Heroku로 배포하는 파이프라인을 만들었습니다. 구성 시작 부분의 복제 섹션을 통해 전체 복제를 수행할 수 있습니다(그렇지 않으면 Heroku가 git 푸시를 거부할 수도 있습니다). 이 구성을 Bitbucket에 푸시하면 스테이징에 대한 첫 번째 자동 배포가 실행되는 것을 확인할 수 있습니다.
애플리케이션을 스테이징에 배포하는 성공적인 파이프라인
예상할 수 있듯이, 변경 사항을 프로덕션 브랜치에 병합할 때 프로덕션 환경을 자동으로 릴리스하도록 하려는 경우 프로덕션 브랜치에 다른 브랜치 파이프라인을 추가하면 됩니다. 터미널에서 이 변경을 수행하고 원래 main으로 푸시합니다.
bitbucket-pipelines.yml
image: node:16
clone:
depth: full
pipelines:
branches:
main:
- step:
name: deploy_to_staging
script:
- npm install
- npm test
- git push https://heroku:$HEROKU_API_KEY@git.heroku.com/thawing-river-12585.git main
production:
- step:
name: deploy_to_production
script:
- npm install
- npm test
- git push https://heroku:$HEROKU_API_KEY@git.heroku.com/fierce-basin-45507.git production:mainmain의 git 푸시 URL을 git remote -vv의 스테이징 URL로 바꾸고 프로덕션용 git 푸시 URL을 git remote -vv의 production URL로 대체해야 합니다.
애플리케이션을 릴리스하기 전에 빌드에 영향을 주지 않는지 확인하기 위해 프로덕션 브랜치에서 테스트를 다시 실행합니다.
이제 파이프라인이 구성되었으며, 프로덕션 브랜치가 풀리퀘스트를 통한 병합만 허용하도록 제한할 수 있습니다. 리포지토리 설정 아래의 워크플로 > 브랜치 권한으로 이동하여 프로덕션 브랜치를 제한하면 됩니다. 로컬 머신에서 곧바로 프로덕션으로 푸시하는 것을 방지하기 원하므로 중요한 단계입니다.
프로덕션 브랜치의 권한 구성
위의 스크린샷에서 다음과 같은 권한을 확인할 수 있습니다.
- 쓰기 권한이 있는 사용자가 없음
- 개발자 한 명만 브랜치에 병합할 수 있음
또한 코드를 병합하기 전에 소스 브랜치에 최소 하나의 녹색 빌드가 있는지 확인하기 위해 병합 검사를 추가했습니다. 그러면 빌드 시간을 절약하고 개발자가 잘못된 코드를 프로덕션 브랜치에 병합하는 일을 방지할 수 있습니다.
완료되면 풀리퀘스트를 만들어 main에서 production으로 코드를 병합한 다음 새 변경 사항을 프로덕션 환경에 릴리스할 수 있습니다.
풀리퀘스트를 만들어 프로덕션에 변경 사항 병합
풀리퀘스트를 병합하는 즉시 프로덕션 브랜치에 대해 새 파이프라인이 트리거되는 것을 확인할 수 있습니다.
완료되면 새 변경 사항이 프로덕션 환경에 성공적으로 배포됩니다.
프로덕션 환경이 최신 상태입니다.
이제 Bitbucket Pipelines를 사용하여 지속적 배포 워크플로를 만들었으며 풀리퀘스트를 사용하여 고객에게 코드를 안전하게 릴리스할 수 있습니다.
이 예시의 최종 소스는 아래 링크의 리포지토리에서 찾을 수 있습니다.
릴리스에 대한 수동 트리거를 통한 지속적 제공
이 구성은 트렁크 기반 개발을 수행하는 팀에 아주 적합합니다.
Bitbucket Pipelines를 사용하면 수동으로 트리거할 수 있는 사용자 지정 파이프라인을 구성할 수 있습니다. 일부 푸시에 대해서만 실행하려는 오래 걸리는 테스트나 사용자가 직접 제어하려는 특정 동작과 같이 다양한 목적으로 사용할 수 있습니다. 사용자 지정 파이프라인을 사용하여, main 브랜치에 대한 푸시를 스테이징 환경에 자동으로 배포하며 커밋을 프로덕션에 수동으로 배포할 수 있는 지속적 제공 워크플로를 설정해 보겠습니다.
스테이징 배포를 설정했으므로 bitbucket-pipelines.yml 구성에 사용자 지정 파이프라인을 추가하면 됩니다. 이 파이프라인은 릴리스를 프로덕션으로 수동으로 트리거하는 데 사용할 것입니다.
bitbucket-pipelines.yml
image: node:16
clone:
depth: full
pipelines:
branches:
main:
- step:
name: deploy_to_staging
script:
- npm install
- npm test
- git push https://heroku:$HEROKU_API_KEY@git.heroku.com/thawing-river-12585.git main
custom:
prod-deployment:
- step:
name: deploy_to_production
script:
- npm install
- npm test
- git push https://heroku:$HEROKU_API_KEY@git.heroku.com/fierce-basin-45507.git production:mainmain의 git 푸시 URL을 git remote -vv의 스테이징 URL로 바꾸고 프로덕션용 git 푸시 URL을 git remote -vv의 production URL로 대체해야 합니다.
Bitbucket 리포지토리에 새 구성을 푸시한 후에는 커밋으로 이동하여 커밋 정보 아래의 파이프라인 실행 링크를 클릭하여 프로덕션으로의 배포를 트리거할 수 있습니다.
파이프라인 실행 작업은 사용 가능한 사용자 지정 파이프라인을 나열
실행 버튼을 누르면 로그를 모니터링할 수 있는 프로덕션 배포 파이프라인으로 리디렉션됩니다.
파이프라인의 커밋 정보 섹션에서는 사용한 사용자 지정 파이프라인의 이름을 볼 수 있습니다. 이제 지속적 배포를 위해 새로운 Bitbucket Pipelines 구성을 사용할 준비가 되었으며, 프로덕션 환경에서 Hello World를 확인하여 문제가 없었는지 확인할 수 있습니다.
Hello World를 수동 트리거를 사용하여 프로덕션에 배포했습니다
이 예시의 최종 소스는 아래 링크의 리포지토리에서 찾을 수 있습니다.
이 문서 공유
다음 토픽
여러분께 도움을 드릴 자료를 추천합니다.
이러한 리소스에 책갈피를 지정하여 DevOps 팀의 유형에 대해 알아보거나 Atlassian에서 DevOps에 대한 지속적인 업데이트를 확인하세요.
DevOps 커뮤니티
DevOps 학습 경로
