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

NC 를 이용해서 네트워크 IP PORT 잘 되는지 체크 하는 방법 (telnet 안녕)

어느정도 보안이 관리되는 회사에서 서버를 열고 접속 하려고 하면, 접속하려는 PC 에서 접속이 안되는 경우가 많다.

그런데 이게 서버가 안 떠 있는 것인지 서버의 인바운드가 아직 안 열린건지 아니면 중간에 프록시라도 있으면 프록시가 안된건지 구간별로 포트 체크하는 방법이 깔끔하지 않다.

nc 를 이용하면 이러한 네트워크 연결 구간별 테스트를 깔끔하게 할 수 있다.

nc는 “서버”가 되기도 하고 “클라이언트” 가 되기도 한다. 그래서, 네트워크 관리자 입장에서는 아직 그 서버가 구동되어 있지 않더라도 가상의 서버을 열어 포트가 열려 있기는 한지 테스트 할 수 있다.

여기서는 10.1.1.1 서버가 8080 포트를 클라이언트에게 열어줘야 하는 경우를 예로 들어본다.

가상의 서버 열기

nc -lk 8080

이 명령어로 간단히 포트를 열 수 있다. nc 는 netcat 인데 프로그램이 설치 되어 있지 않다면 yum install nc 등으로 간단히 설치 할 수 있다.

클라이언트의 접속 테스트

보통의 경우 windows 에서는 telnet 10.1.1.1 8080 등으로 8080 포트가 열려 있는지를 테스트 할 수 있으나 nc for windows 등을 구해 놓으면 여러모로 편리하다.

nc -zv 10.1.1.1 8080

왜냐면 nc 는 1개 이상의 포트를 스캐닝 하는 기능도 가지고 있다.

nc -zv 10.1.1.1 22-80

22번 포트부터 80포트까지 스캔

windows 10 에서 sendtokindle 을 설치해도 프린터 목록에 안 나올 때

kindle 로 인쇄시켜주는 앱. pdf 를 드래그 해도 되고 인쇄하면서 프린터를 send to kindle 로 선택해도 된다.

send to kindle app 은 send to onenote 와 비슷하게 윈도우에 설치하는 S/W 프린터이다. 해당 프린터로 인쇄를 하면 내 kindle 에 자동으로 저장되는 일종의 cloud printer 다.

언젠가부터 이 앱을 설치해도 프린터 목록에 안 나오는데 이는 send to kindle app의 호환성 때문으로 보인다.

send to kindle 앱의 호환성 개선

C:\Program Files (x86)\Amazon\SendToKindle

에서 sendtokindle.exe 의 호환성을 검사한다.

문제 해결사를 실행하면 해결이 된다. 이것에 되는 것은 처음으로 경험했다!!!

프린터를 수동으로 추가

이후 프린터가 보이는 것을 볼 수 있다.

설치가 완료되면 프린터를 선택할 수 있다.

Eclipse junit test class에서 특정 method만 test 하는 방법

outline view 에서

소스 코드에서

단 반드시 함수 위에서 해야 한다.

물론, 단축키로 함수 위에 커서를 둔 상태에서

alt+shift+x (실행), t (테스트) 를 순차 호출해도 된다.

이제까지 outline view 에서만 되는 줄 알았다. outline view 안녕.

Excel 의 표를 기반으로 한글로된 pdf 파일들을 만들기.

python 으로 엑셀을 읽어서 pdf 출력하는 것은 많은 가이드가 있는데, 우선적으로 생각해야 하는 것이, 한글과 폰트의 문제이다. 여러 가이드를 따라 해봤으나 잘 되지 않는다.

pdf를 만들기 전에 그 출력될 화면까지 미리 볼 수 있으면 얼마나 좋을까?

excel 을 pandas로 읽어서 html 로 저장 후 chrome –headless –print-to-pdf 기능을 이용하여 한방에 해결 하였다.

만들어진 html 을 chrome 으로 열어볼 수도 있고 그것이 pdf로 바뀌는 퀄리티는 의심의 여지가 없다.

다만 pdf출력시 header 와 footer 가 자연히 들어가게 되는데 css로 이것을 없앨 수 있다.

@media print {
  @page { margin: 0; }
  body { margin: 1.6cm; }
}

읽고 싶은 문서를 google drive 에 파일 이름 지정 하면서 PDF 형식으로 저장하기

google drive 를 설치하고 나면? 혹은 chrome 로그인 하고 나면 인쇄 프린터 선택기에 google drive 에 저장하기를 선택할 수 있다.

그런데 최하단에 “이름을 설정” 할 수 있다른 것을 알게 되었다. 왠지 “프린터의 고급 설정” 같이 보이는데..