아티클
튜토리얼
대화형 가이드
Bitbucket Pipelines를 통한 지속적 배포에 대해 알아보기
![Sten Pittet 얼굴 사진](https://wac-cdn.atlassian.com/dam/jcr:57a8bbb8-4f5c-46fc-9ceb-224cf79af3d8/Screen%20Shot%202017-04-14%20at%2010.43.26%20AM.png?cdnVersion=2022)
Sten Pittet
기고 작가
이 가이드에서는 Bitbucket Pipelines를 사용하여 지속적 배포 워크플로를 채택하는 방법을 살펴보겠습니다. 계속 읽어보세요.
시간
30분
대상 그룹
지속적 배포 및/또는 Bitbucket Pipelines를 처음 사용하는 사용자입니다.
새로운 기능을 릴리스할 때는 고객에게 새로운 기능을 제공하게 되므로 항상 흥미로운 순간입니다. 그러나 준비가 많이 필요한 위험한 작업이 될 수도 있으므로 팀이 잦은 릴리스를 꺼릴 수도 있습니다. 기다리는 시간이 길수록 프로덕션에 배포하기가 더 어려워집니다. 변경 사항이 쌓이고 변경 사항의 범위를 이해하기 어렵게 되며, 프로덕션에서 문제가 발생하면 근본 원인을 파악하기 힘듭니다.
소프트웨어 배포에 대한 두려움을 없애고 비용을 낮추는 간단한 방법은 소프트웨어를 자동화하고 작은 변경 사항을 더 자주 릴리스하는 것입니다. 우선 일반적으로 릴리스를 준비하는 데 걸리는 긴 시간을 절약할 수 있습니다. 각 릴리스의 범위가 훨씬 작아져서 소프트웨어 배포의 위험 역시 줄어들게 되므로 환경을 모니터링하고 문제를 해결하기가 쉬워집니다.
이런 배포 자동화는 지금은 Bitbucket Cloud를 통해 쉽게 할 수 있는 작업입니다. 각 리포지토리에 대해, 푸시할 때마다 코드를 자동으로 빌드, 테스트 및 환경에 배포하는 파이프라인을 구성할 수 있습니다. 이 가이드에서는 Bitbucket Pipelines를 사용하여 지속적 배포 워크플로를 채택하는 방법을 살펴보겠습니다.
지속적 제공 및 지속적 배포 비교
지속적 제공은 모든 변경 사항을 프로덕션에 배포하지 않더라도 코드를 항상 릴리스할 준비가 되었는지 확인하는 것입니다. 가능한 한 자주 프로덕션을 업데이트하여 변경 사항의 범위를 작게 유지하는 것이 좋지만 결국 릴리스의 리듬을 제어하는 것은 사용자입니다.
지속적 배포에서 리포지토리에 푸시된 새 변경 사항은 테스트를 통과하면 자동으로 프로덕션에 배포됩니다. 이것은 테스트 문화를 더 강조(또는 압박)하지만 고객과의 피드백 루프를 가속화하는 좋은 방법입니다.
![지속적 배포와 지속적 개발 간의 차이점을 보여주는 다이어그램 | Atlassian CI/CD](https://wac-cdn.atlassian.com/dam/jcr:a0607dd7-7423-44e7-bf7d-ce24e9518ada/cicd-CIvsCD.png?cdnVersion=2022)
지속적 제공 파이프라인 채택
이 예시에서는 빌드가 테스트를 통과하면 스테이징에 자동으로 배포하는 지속적 제공 파이프라인을 추가하여 지속적 통합 자습서에서 구축한 간단한 node.js 앱을 확장합니다. 프로덕션 배포에 대한 두 가지 전략을 살펴보겠습니다. 하나는 브랜치 및 풀리퀘스트를 사용하며 다른 하나는 사용자 지정 파이프라인 및 수동 트리거를 사용합니다.
두 예시 모두에서 브라우저에 "Hello World"라는 메시지를 표시하는 간단한 Node.js 애플리케이션을 사용합니다. 두 가지 방법을 모두 사용하여 Heroku에서 호스팅되는 스테이징 및 프로덕션 환경에 이 애플리케이션을 배포할 것입니다.
![기본적인 Hello World 애플리케이션 | Atlassian CI/CD](https://wac-cdn.atlassian.com/dam/jcr:b847c010-b3a1-4e37-b89e-ec53302298ae/Screen%20Shot%202017-04-12%20at%204.42.33%20PM.png?cdnVersion=2022)
가장 기본적인 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 start
Heroku에 로그인하여 오른쪽 상단에 있는 사용자 아이콘을 클릭하고 계정 설정을 클릭한 다음 아래로 스크롤하여 API 키를 찾습니다.
![Heroku 계정 설정에서 API 키 찾기](https://wac-cdn.atlassian.com/dam/jcr:b1039721-a65e-4163-8bcd-f27810d47d51/api-key.png?cdnVersion=2022)
다음으로, Heroku에 배포할 수 있도록 Bitbucket Pipelines에 환경 변수를 추가합니다.
- HEROKU_API_KEY: API 키는 Heroku 계정에서 찾을 수 있습니다
리포지토리 설정에서 파이프라인 > 환경 변수로 이동하여 이 변수를 추가합니다.
![Bitbucket에서 Heroku를 설정하는 스크린샷 | Atlassian CI/CD](https://wac-cdn.atlassian.com/dam/jcr:98851d83-208b-40be-83e2-6d0e92331f23/CDmicro-600x338-retina2x-F_12-14-9.png?cdnVersion=2022)
Heroku에 배포할 환경 변수 설정
이 가이드에서는 Heroku를 사용하고 있으며, 이 예시는 다른 호스팅 서비스에도 적용할 수 있습니다. 이 가이드를 Heroku 참고 자료로 사용하세요.
브랜치를 프로덕션의 게이트로 사용하는 지속적 배포
이 구성은 배포에 매핑할 수 있는 특수 릴리스 브랜치가 있는 팀에 적합합니다. 또한 풀리퀘스트에서의 변경 사항을 프로덕션에 배포하기 전에 검토할 수 있습니다.
이 설정에서는 다음과 같이 서로 다른 두 브랜치를 사용하여 배포를 트리거합니다.
- main: main으로 푸시할 때마다 테스트 실행 후 스테이징 환경에 코드가 배포됩니다.
- production: production 브랜치에 병합된 코드는 자동으로 프로덕션 환경으로 릴리스됩니다.
브랜치를 클릭하여 Bitbucket Cloud에서 프로덕션 브랜치를 만듭니다
![Bitbucket Cloud의 프로덕션 브랜치](https://wac-cdn.atlassian.com/dam/jcr:507a590d-076a-4040-ad4b-657ddecd2b2f/production-branch.png?cdnVersion=2022)
그런 다음 브랜치 만들기를 클릭합니다
![Bitbucket Cloud의 팝업 창에서 "브랜치 만들기" 선택](https://wac-cdn.atlassian.com/dam/jcr:ece518a0-cd40-48b8-a1e7-55b23f7af57e/create-branch.png?cdnVersion=2022)
production을 입력하고 만들기를 클릭합니다.
예시 리포지토리의 루트 디렉터리에서 다음을 실행합니다.
heroku create --remote staging
git push staging main
heroku create --remote production
git push production main
제대로 작동하는지 확인하려면 브라우저에서 Heroku로 이동하여 두 개의 앱이 있는지 확인하세요.
![Heroku 브라우저에 나열된 앱](https://wac-cdn.atlassian.com/dam/jcr:e25e9383-83de-498b-9ee4-0d4d56bb6280/heroku-browser.png?cdnVersion=2022)
다음을 실행합니다.
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 main
main에 대한 git 푸시 URL을 위에 있는 git remote -vv의 스테이징 URL로 바꿔야 합니다.
이제 애플리케이션을 빌드 및 테스트한 후 main에서의 모든 푸시를 Heroku로 배포하는 파이프라인을 만들었습니다. 구성 시작 부분의 복제 섹션을 통해 전체 복제를 수행할 수 있습니다(그렇지 않으면 Heroku가 git 푸시를 거부할 수도 있습니다). 이 구성을 Bitbucket에 푸시하면 스테이징에 대한 첫 번째 자동 배포가 실행되는 것을 확인할 수 있습니다.
![성공적인 파이프라인 배포의 스크린샷 | Atlassian CI/CD](https://wac-cdn.atlassian.com/dam/jcr:1ffbd382-91e2-46cf-841f-f2d25fc4909d/CDmicro-600x338-retina2x-E_12-3-1.png?cdnVersion=2022)
애플리케이션을 스테이징에 배포하는 성공적인 파이프라인
예상할 수 있듯이, 변경 사항을 프로덕션 브랜치에 병합할 때 프로덕션 환경을 자동으로 릴리스하도록 하려는 경우 프로덕션 브랜치에 다른 브랜치 파이프라인을 추가하면 됩니다. 터미널에서 이 변경을 수행하고 원래 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:main
main의 git 푸시 URL을 git remote -vv의 스테이징 URL로 바꾸고 프로덕션용 git 푸시 URL을 git remote -vv의 production URL로 대체해야 합니다.
애플리케이션을 릴리스하기 전에 빌드에 영향을 주지 않는지 확인하기 위해 프로덕션 브랜치에서 테스트를 다시 실행합니다.
이제 파이프라인이 구성되었으며, 프로덕션 브랜치가 풀리퀘스트를 통한 병합만 허용하도록 제한할 수 있습니다. 리포지토리 설정 아래의 워크플로 > 브랜치 권한으로 이동하여 프로덕션 브랜치를 제한하면 됩니다. 로컬 머신에서 곧바로 프로덕션으로 푸시하는 것을 방지하기 원하므로 중요한 단계입니다.
![프로덕션 브랜치의 권한 구성 | Atlassian CI/CD](https://wac-cdn.atlassian.com/dam/jcr:d1bfc740-77ea-4b0c-8381-d5f45105d748/CDmicro-600x338-retina2x-E_12-4-9.png?cdnVersion=2022)
프로덕션 브랜치의 권한 구성
위의 스크린샷에서 다음과 같은 권한을 확인할 수 있습니다.
- 쓰기 권한이 있는 사용자가 없음
- 개발자 한 명만 브랜치에 병합할 수 있음
또한 코드를 병합하기 전에 소스 브랜치에 최소 하나의 녹색 빌드가 있는지 확인하기 위해 병합 검사를 추가했습니다. 그러면 빌드 시간을 절약하고 개발자가 잘못된 코드를 프로덕션 브랜치에 병합하는 일을 방지할 수 있습니다.
완료되면 풀리퀘스트를 만들어 main에서 production으로 코드를 병합한 다음 새 변경 사항을 프로덕션 환경에 릴리스할 수 있습니다.
![풀리퀘스트를 만드는 과정을 보여주는 Bitbucket 스크린샷 | Atlassian CI/CD](https://wac-cdn.atlassian.com/dam/jcr:7b2112ae-b0ee-45c4-90c4-eb4a81fab0bd/CDmicro-600x338-retina2x-E_12-7-0.png?cdnVersion=2022)
풀리퀘스트를 만들어 프로덕션에 변경 사항 병합
풀리퀘스트를 병합하는 즉시 프로덕션 브랜치에 대해 새 파이프라인이 트리거되는 것을 확인할 수 있습니다.
![파이프라인이 풀리퀘스트에 의해 성공적으로 트리거되었습니다 | Atlassian CI/CD](https://wac-cdn.atlassian.com/dam/jcr:5241b0ef-028e-4708-888c-00c5dc23302a/CDmicro-600x338-retina2x-E_12-8-25.png?cdnVersion=2022)
완료되면 새 변경 사항이 프로덕션 환경에 성공적으로 배포됩니다.
![프로덕션 환경이 최신 상태임을 확인하는 "Hello World!" 메시지](https://wac-cdn.atlassian.com/dam/jcr:fca6d3e1-e72d-431e-90e2-71da46e6d84e/Screen%20Shot%202017-04-14%20at%2010.13.30%20AM.png?cdnVersion=2022)
프로덕션 환경이 최신 상태입니다.
이제 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:main
main의 git 푸시 URL을 git remote -vv의 스테이징 URL로 바꾸고 프로덕션용 git 푸시 URL을 git remote -vv의 production URL로 대체해야 합니다.
Bitbucket 리포지토리에 새 구성을 푸시한 후에는 커밋으로 이동하여 커밋 정보 아래의 파이프라인 실행 링크를 클릭하여 프로덕션으로의 배포를 트리거할 수 있습니다.
![Bitbucket에서 파이프라인 선택 및 실행](https://wac-cdn.atlassian.com/dam/jcr:b508b099-6d20-490e-b3d3-10ed694e7e90/CDmicro-600x338-retina2x-E_12-11-27.png?cdnVersion=2022)
파이프라인 실행 작업은 사용 가능한 사용자 지정 파이프라인을 나열
실행 버튼을 누르면 로그를 모니터링할 수 있는 프로덕션 배포 파이프라인으로 리디렉션됩니다.
![Bitbucket의 프로덕션 배포 파이프라인](https://wac-cdn.atlassian.com/dam/jcr:fa88b8e7-ce63-4c08-9867-c151824d0f7b/CDmicro-600x338-retina2x-E_12-12-21.png?cdnVersion=2022)
파이프라인의 커밋 정보 섹션에서는 사용한 사용자 지정 파이프라인의 이름을 볼 수 있습니다. 이제 지속적 배포를 위해 새로운 Bitbucket Pipelines 구성을 사용할 준비가 되었으며, 프로덕션 환경에서 Hello World를 확인하여 문제가 없었는지 확인할 수 있습니다.
![프로덕션의 "Hello World!" 테스트 메시지](https://wac-cdn.atlassian.com/dam/jcr:7a09aaa1-d22e-4a1e-ab09-23955e6250ac/Screen%20Shot%202017-04-14%20at%2010.23.33%20AM.png?cdnVersion=2022)
Hello World를 수동 트리거를 사용하여 프로덕션에 배포했습니다
이 예시의 최종 소스는 아래 링크의 리포지토리에서 찾을 수 있습니다.
이 문서 공유
다음 주제
여러분께 도움을 드릴 자료를 추천합니다.
이러한 리소스에 책갈피를 지정하여 DevOps 팀의 유형에 대해 알아보거나 Atlassian에서 DevOps에 대한 지속적인 업데이트를 확인하세요.
![DevOps 일러스트레이션](https://wac-cdn.atlassian.com/dam/jcr:bd9d8b2c-ca36-444f-8595-719cb1990e64/Devops-community.png?cdnVersion=2022)
DevOps 커뮤니티
![DevOps 일러스트레이션](https://wac-cdn.atlassian.com/dam/jcr:297108ea-d232-4368-af51-b53af230c4fe/Simulation-workshop.png?cdnVersion=2022)
DevOps 학습 경로
![맵 일러스트레이션](https://wac-cdn.atlassian.com/dam/jcr:25f6330a-4191-408f-a4e5-2e24bfba67b4/Maturity-model.png?cdnVersion=2022)