Deployment projects (of Bamboo)

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:
아래 그림 한번 봐봐라

Continuous Delivery is the practice where all changes made to a software project are automatically built, tested and made ready for deployment to users. In practice, once the project has been built and tested it is ‘staged’ somewhere where it can be manually verified and then made available to users.

Unlike Continuous Deployment (the process where code changes are automatically built, tested and deployed without human intervention), typically there is a decision made by a human being to whether or not the software is of sufficient quality or if it is the correct time for the business to make the software available to its users.

Continuous Delivery 와 Deployment 의 차이로, 배포 직전까지만 하느냐 배포까지 자동화 하느냐 용어 나누기를 하는 듯.

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 가 돌고 있는지 무엇이 교체될 것인지 언제 누가 배포 했는지 볼 수 있다.

Smartphone app을 타블렛 모드로 가동 시키기 OneNote / Chrome :: 개발자 모드의 최소 폭 조정으로

OneNote를 최고의 노트앱으로 생각하는 나의 최대 불만은 Sytle 기능을 사용 할 수 없다는 것.

  • 안드로이드 원노트 앱에서 스타일 사용하기
  • 안드로이드 크롬에서 탭 사용하기
Sytle 지원

그래서 약간의 조사를 해보니 개발자 옵션에서 최소 폭 이라는 것을 발견했다. 3~4년 전에 한참 루팅에 관심 있을 때 설정하던 density 개발자 모드에 있던 것이었다.


510을 넘어가는 순간 OneNote는 타블렛 모드로 동작한다.

이 숫자를 510 이상으로 변경하게 되면, 스마트폰 화면의 모든 것들이 작아진다. 아이콘과 글씨가 급 작아지게 되는데 글씨도 안 보인다면 폰트를 크게 키우면 된다. 그리고 화면의 해상도를 바꾸면 최소 폭이 Default 값으로 돌아간다.

OneNote Tablet mode

앱을 닫았다가 (멀티테스킹 창에서 휙~ 날려버리면) 다시 열면 타블렛 모드로 동작하게 되면서 OneNote에 탭이 나오고 스타일 기능을 쓸 수 있게 된다.

Chrome tablet mode

한가지 더 실험을 하였다. chorme의 경우에도 mobile view의 경우는 내가 탭이 도데체 몇개나 열려있는지 알기가 어렵고, 나중에 보면 탭이 100개도 넘게 열려 있다. 그래서 tablet 모드로 돌리려면 최소 폭을 얼마나 해야 하는지 확인해 보니 600이다.


스마트폰의 chrome app 이 tablet 모드로 동작

chrome은 뜻하지 않게 탭만 열려고 했는데 새탭에서 추천 도움말이 나오기도 한다.

요즘 스마트폰의 해상도가 대단한데 시력만 좋다면 그 화면을 더 넓게 사용할 수 있는 좋은 방법인 것 같다.

단점

화면 회전 추천 버튼이 뜨지 않음

유튜브 최대화 했을 때. 가로 세로비 문제 앱으로 해결해야 할 듯