bamboo 의 Deployment projects 에 대한 문서를 번역해 본다.

What are deployment projects?

A deployment project in Bamboo is a container for holding the software project you are deploying: releases that have been built and tested, and the environments to which releases are deployed. Teams typically have QA, staging and production environments. 

Bamboo 의 deployment project 는 니가 배포하려는 개발 프로젝트, 니가 빌드하고 테스트한 releases, 그리고 releases 들이 배포될 environments 에 대한 container 이다.

Why use deployment projects?

Continuous Integration was not designed for Continuous Delivery. Continuous Integration is designed to keep developers informed about the state of the latest code changes.

CI는 CD를 위해 디자인 되지 않았다. CI는 개발자에게 마지막 코드 변경에 대한 상태 안내를 한다.

In Continuous Integration, historical build results (along with information such as issue and commits) are de-emphasized as more changes are made, since only the latest build is important to the developer.

CI 에서는 많은 변화에 비해서 빌드 결과 히스토리는 덜 중요하다. 개발자에게는 최신의 빌드만이 중요하기 때문이다.

Using a traditional Continuous Integration server for Continuous Delivery is less than ideal because:

기존에 CD를 지원하는 CI 서버는 좀 이상적이지 않다. 왜냐면..

• Deployed builds are difficult to find – Builds that were deployed only a few days ago are de-emphasized by the system. While this is good for a Continuous Integration workflow, the behavior makes it difficult for team members to identify which builds have been deployed and when, versus which have not. Teams can work around this with a system that uses labeling but it’s not immediately obvious how it should work unless team members are trained to use it correctly.
  배포된 빌드는 찾기가 어렵다. – 몇일전에 배포된 builds는 시스템이 덜 강조한다. (추적이 어려워 진다는 뜻인 듯). CI 측면에서는 좋은 반면, 이것은 어떤 빌드가 언제 배포 되었으며 어떤 빌드는 배포 되지 않았는지 알기 어렵게 한다. 라벨링을 매기는 등으로 수동처리(?) 할 수 있지만 직관적이지는 않다.
• Difficult to find what changes were made between deployments – Build results report commit and issue data between a specific build result and the one immediately before it. There can be many build results between two different deployments. Often the entire history has to be navigated between the two deployments to build a complete view of the changes between them. Sometimes, even other tools have to be used, such as version control systems.
  배포와 배포 사이에 어떤 변경이 만들어 졌는지 찾기 어렵다. – build 결과는 커밋과 이슈들의 특정 빌드과 그 직전 빌드의 차이를 알려준다. 그런대 2개의 배포 사이에는 더 많은 빌드가 있을 수 있다. 종종 VCS 등을 별도의 툴을 사용해 2개의 배포 사이의 모든 변경을 추적해야만 한다.
• Difficult to know what was deployed, and when and where it was deployed – Builds do not have visibility of where code is deployed or what was previously deployed to an environment.
• 무엇이 배포 되었는지 언제 어디서 배포 되었는지 찾기 어렵다. Builds 는 어디애 배포되었는지 알기 어렵고 직전 배포는 어디에 되었는지도 알기 어렵다.
• Lack of insight into the QA process – Given a list of deployment candidates, builds offer no clear way (other than commenting or labeling) for QA to ‘sign off’ on a tested release or mark a release as broken or un-releasable.
  QA 프로세스를 위한 통찰력이 부족하다.
• Poor control over who can deploy – While it can be controlled by permissions who can run, view or edit a build, they do not give enough fine grained control over which people in the team can deploy to production or other sensitive environments. In essence, if someone has permission to run the build they can deploy the software any time they wish.
  배포 권한 설정이 어려움 – 누가 배포 하고 배포 했음을 볼 수 있는지

To solve these issues Bamboo provides the following concepts:
이런저런 이유로 Bamboo 가 아랫것들을 제공한다.

• Deployment project – Represents the software you are deploying (such as a web application), the releases of the software deployed and the environments that they will be deployed to throughout the lifecycle.
  Deployment project – 니가 배포 하고 있는 것 그 자체, 배포된 것들와 배포될 환경
• Environment – Represents the servers or groups of servers where the software release has been deployed to, and the tasks that are needed for the deployment to work smoothly. Example environments could be named Development, QA, Staging or Production. Environments have permissions that allow fine grained control of who can deploy, edit or view an environment and record the full history of releases deployed to it.
  Environment  – 배포될 서버 그룹, 배포가 원활하게 진행되기 위해 필요한 작업들. 배포 환경은 Dev, QA, STG, PROD 가 될 수 있다. Environments 각 환경별로 배포 하기/보기 권한을 나눌 수 있다.
• Release – Identifies a snapshot of artifacts and its associated data such as commits, Jira issues and the builds that were used to test it. As a release contains the information of the difference between itself and the release beforehand, it’s very easy to see the changes between releases or to show the difference between the software deployed on two different environments. Releases also track what environments they have been deployed to.
  Release – 특정 시점의 artifacts 스냅샷 그 자체 관련된 커밋과 이슈들. 릴리즈간의 차이점을 확인 하기 쉽게 해준다.

How do deployment projects work?

Consider the following diagram:
아래 그림 한번 봐봐라

Artifacts

Create and test deployable artifacts with build plans. Ensure any artifacts you wish to deploy with Bamboo are flagged as “shared” to make them available to the deployment instructions of the environment.

build plans 으로 배포 가능한 artifacts 를 만들고 테스트 한다. Bamboo 통해서 배포되길 원하면 shared 설정이 되어야 한다.

Releases

Any artifact that has been successfully tested can be used to create a release; you can create as many releases as you like. Bamboo will add other metadata such as related commits and Jira issues to each release which enable reporting and tracking as it moves through your environments.

테스트된 artifact 라면 release 가 만들어지는데 사용될 수 있다. (테스트 끝난 artifact) Bamboo 는 release 에 Jira 이슈나 커밋을 관련짓는 메타를 만든다.

Environments

Environments in Bamboo reflect the development, testing and production environments in your IT infrastructure – hostnames and authentication credentials for each environment reside at the task level inside your deployment jobs. At any point in time, you will be able to see which release is running in each environment, which release it replaced, when it was deployed and who deployed it. You will also be able to see any associated Jira issues.

Bamboo 에서 Environments 는 당신네 개발, 테스팅, 운영환경을 말한다. hostname 각 배포를 위한 인증 키등. environments 별로 어떤 release 가 돌고 있는지 무엇이 교체될 것인지 언제 누가 배포 했는지 볼 수 있다.