[Hyperledger Indy Docs] Indy Node: 10. Continuous Integration / Delivery

이 글은 Hyperledger Indy의 공식 문서를 번역한 것입니다.
원본 사이트 : https://hyperledger-indy.readthedocs.io/projects/node/en/latest/ci-cd.html

 

Branches(브랜치)

• master 브랜치는 최신 변경 사항을 포함합니다. 모든 PR은 보통 master에게 보내야합니다.
• stable 브랜치는 최신 릴리즈(https://github.com/hyperledger/indy-node/releases)를 포함합니다. Hotfixes는 stable 및 master로 보내야합니다.
• release-* 브랜치에는 release 워크 플로우 중에 릴리즈 후보가 포함됩니다.
• hotfix-* 브랜치에는 hotfix 워크 플로우 중에 릴리즈 후보가 포함됩니다.

 

Pull Requests

• 각 PR을 검토해야합니다.
• 모든 테스트를 통과하고 코드를 검토한 후에만 PR을 병함(merge)할 수 있습니다.

 

Continuous Integration(지속적인 통합)

• 각 PR에 대해 다음을 실행합니다.
  • static 코드 유효성 검사
  • 단위/통합 테스트
• 우리는 코드 접근 방식의 파이프 라인과 Jenkins를 주요 CI/CD 서버로 사용합니다.
• 파이프 라인의 CI 부분(각 PR에 대해 테스트 실행)은 Jenkinsfile.ci 파일에 정의되어 있습니다.
• CI 부분은 Hyperledger 및 Sovrin Foundation Jenkins 서버에서 실행되므로 모든 contributor가 자신의 PR에 대해 실행된 테스트 결과를 확인해야하기 때문에 public 및 open 됩니다.

 

Static Code Validation(Static 코드 검증)

• static 코드 검증에는 flake8을 사용합니다.
• 모든 PR에 대해 실행됩니다. static 코드 검증 오류가 있으면 PR이 실패합니다.
• 모든 검사가 활성화되어 있지는 않습니다(프로젝트 root에서 .flake8 파일을 살펴보십시오)
• static 코드 검증을 로컬로 실행할 수 있습니다:
  • flake8 설치: pip install flake8
  • 프로젝트의 root 폴더에서 유효성 검증을 실행하십시오: flake8 .

 

Continuous Delivery(지속적인 배달)

• 파이프 라인의 CD 부분은 Jenkinsfile.cd 파일에 정의되어 있습니다.
• CD 부분은 새로운 빌드 발행 및 업로드를 처리하는 Sovrin Foundation Jenkins 서버에서 실행됩니다.

 

Builds

각 push 후 생성되는 아티팩트

• master 브랜치:
  • 모든 아티팩트에는 해당 버전의 개발 릴리즈 세그먼트인 devN이 포함됩니다.
  • indy-plenum:
    • pypi의 indy-plenum
    • https://repo.sovrin.org/deb xenial master-latest의 indy-plenum deb 패키지
  • indy-node:
    • pypi의 indy-node
    • https://repo.sovrin.org/deb xenial master-latest의 indy-node deb 패키지
    • https://repo.sovrin.org/deb xenial master의 indy-node deb 패키지 (master-latest에서 복사)
    • https://repo.sovrin.org/deb xenial master의 indy-plenum deb 패키지 (master-latest에서 복사)
• release-* 및 hotfix-* 브랜치:
  • 모든 아티팩트에는 해당 버전의 pre-릴리즈 세그먼트인 rcN이 포함됩니다.
  • indy-plenum:
    • pypi의 indy-plenum
    • https://repo.sovrin.org/deb xenial rc-latest의 indy-plenum deb 패키지
  • indy-node:
    • pypi의 indy-node
    • https://repo.sovrin.org/deb xenial rc-latest의 indy-node deb 패키지
    • https://repo.sovrin.org/deb xenial rc의 indy-node deb 패키지 (rc-latest에서 복사)
    • https://repo.sovrin.org/deb xenial rc의 indy-plenum deb 패키지 (rc-latest에서 복사)
• stable 브랜치:
  • indy-plenum:
    • pypi의 indy-plenum
    • https://repo.sovrin.org/deb xenial stable-latest의 indy-plenum deb 패키지
    • indy-plenum 릴리즈 태그(https://github.com/hyperledger/indy-plenum/releases)
  • indy-node:
    • pypi의 indy-node
    • https://repo.sovrin.org/deb xenial stable-latest의 indy-node deb 패키지(rc-latest에서 리패키징)
    • https://repo.sovrin.org/deb xenial stable의 indy-node deb 패키지 (rc-latest에서 복사)
    • https://repo.sovrin.org/deb xenial stable의 indy-plenum deb 패키지 (stable-latest에서 복사)
    • indy-node 릴리즈 태그(https://github.com/hyperledger/indy-node/releases)

아티팩트 사용 사례

• PyPI 아티팩트트는 개발 환경에 사용될 수 있지만 프로덕션 환경에는 사용되지 않습니다.
• Ubuntu 환경의 test/production pool에서 사용될 경우 deb 패키지를 사용하는 것이 좋습니다.
  • https://repo.sovrin.org/deb xenial stable의 indy-node deb 패키지는 프로덕션 환경에 사용할 수 있는 유일한 공식 stable 릴리즈입니다(stable 버전).
  • https://repo.sovrin.org/deb xenial master의 indy-node deb 패키지에는 최신 변경 사항(master 브랜치의)이 포함되어 있습니다. 이 코드가 충분히 stable한 것은 아닙니다.

 

Packaging

Supported platforms and OSes(지원되는 플랫폼 및 OS)

• Ubuntu 16.04의 x86_64

 

Build scripts(빌드 스크립트)

우리는 python 코드를 deb 패키지로 패키징하기 위해 fpm을 사용합니다. 빌드 스크립트는 build-scripts 폴더에 있습니다:

• https://github.com/hyperledger/indy-node/blob/master/build-scripts
• https://github.com/hyperledger/indy-plenum/blob/master/build-scripts

또한 표준 Ubuntu repository에 표시되지 않은 일부 3rd party dependency를 패키지합니다.

• https://github.com/hyperledger/indy-node/blob/master/build-scripts/ubuntu-1604/build-3rd-parties.sh
• https://github.com/hyperledger/indy-plenum/blob/master/build-scripts/ubuntu-1604/build-3rd-parties.sh

각 build-scripts 폴더에는 Readme.md가 포함되어 있습니다. 자세한 내용은 해당 파일을 참조하십시오.

 

Versioning

• 우리는 SemVer를 만족시키는 MAJOR.MINOR.PATCH와 같은 릴리즈 세그먼트를 가진 PEP 440을 만족시키는 버전 관리를 사용하고 있습니다.
• 코드에 버전이 설정되어 있습니다(__version__.json 참조).
• 수동으로 또는 bump_version.sh 스크립트를 사용하여 새 릴리즈/hotifx 버전이 bump됩니다. 후자가 더 좋습니다.
• 개발 단계 버전에서는 개발 세그먼트인 devN이 포함되며, 여기서 N은 서버 작업 빌드의 증가된 빌드 번호로 CD 파이프 라인 아티팩트에 대해 설정됩니다. 소스 코드에서는 항상 0과 같습니다.
• 릴리즈 준비 단계(릴리즈/hotfix 워크 플로우) 버전에는 pre-릴리즈 세그먼트인 rcN이 포함되며, 여기서 N>=1이며 개발자가 소스 코드에 설정합니다.
• 각 dependency(indy-plenum 포함)의 버전은 엄격합니다(setup.py 참조).
• pypi 또는 deb 패키지에서 indy-node를 설치하면 setup.py 버전의 indy-plenum에 지정된 indy-plenum이 설치됩니다.
• master와 stable은 동일한 버전 관리 체계를 공유합니다.
• master와 stable 코드의 차이점:
  • setup.py: 다른 버전의 indy-plenum dependency
  • 마이그레이션 스크립트의 다른 버전

 

For releases < 1.7.0(deprecated) (< 1.7.0 릴리즈(더 이상 사용되지 않음))

• 우리는 각 구성 요소에 대한 버전 관리(major, minor, build)에 semver-like 접근법을 사용하고 있습니다.
• major와 minor 부분이 코드에 설정되어 있습니다(__metadata__.py 참조). 필요한 경우 코드에서 수동으로 새로운 릴리즈에 대해 증가시켜야합니다.
• 빌드 부분은 Jenkins에서 각 빌드마다 증가시킵니다(따라서 항상 증가하긴 하지만, 순차적이지 않을 수 있습니다).
• 각 dependency(indy-plenum 포함)의 버전은 엄격합니다(setup.py 참조).
• pypi 또는 deb 패키지에서 indy-node를 설치하면 setup.py에 명시된 버전의 indy-plenum이 설치됩니다.
• Master 및 Stable 빌드는 일반적으로 버전이 다릅니다.
• master와 stable 코드의 차이점:
  • setup.py:
    • 프로젝트 이름의 개발 접미사(suffix) 및 master의 indy-plenum dependency; stable은 접미사(suffix) 없음
    • 다른 버전의 indy-plenum dependency
  • 다른 버전의 마이그레이션 스크립트

 

Release workflow(릴리즈 워크 플로우)

Feature Release(기능 릴리즈)

1. Release Candidate Preparation(릴리즈 후보 준비)

1. [Maintainer]

• stable에서 release-X.Y.Z 브랜치를 생성(첫 번째 RC 준비 중에만)

2. [Contributor]

• release-X.Y.Z에서 rc-X.Y.Z.rcN 브랜치를 생성(N은 1에서 시작하여 새로운 RC마다 증가)
• master에서 필요한 변경 사항을 적용(merge 또는 cherry-pick)
• (선택 사항) [indy-node] setup.py에서 indy-plenum 버전 설정
• 패키지 버전 설정 ./bump_version.sh X.Y.Z.rcN
• release-X.Y.Z에 commit, push 및 PR 생성

3. PR이 병합될 때까지:

1. [build server]
   • PR에 CI를 실행하고 GutHub에 알림
2. [Maintainer]
   • PR 검토
   • 변경을 요청하거나 merge
3. [Contributor]
   • (선택 사항) CI가 실패했거나 검토자가 변경을 요청한 경우 PR을 업데이트
   • (선택 사항) [indy-node] 변경 사항에 새로운 indy-plenum 릴리즈가 필요한 경우 setup.py에서 indy-plenum 버전을 bump합니다.

 

2. Release Candidate Acceptance(릴리즈 후보 발표)

참고: 다음 단계 중 하나라도 실패하면 새로운 릴리즈 후보를 준비해야합니다.

1. [Maintainer]

• 릴리즈 후보 파이프 라인을 수동으로 시작

2. [build server]

• 저장소 체크아웃(repository checkout)
• X.Y.Z.rcN으로 PyPI에 게시
• X.Y.Z 근처에 버전을 bump하고, release commit으로 원격에 commit 및 push
• debian 패키지 빌드:
  • 프로젝트의 경우: 소스 코드 버전은 X.Y.Z, debian 패키지 버전은 X.Y.Z~rcN;
  • 공식 debian 저장소에서 누락된 3rd party dependency에 대해
• 패키지를 rc-latest debian 채널에 게시
• [indy-node] rc-latest에서 rc 채널로 패키지(indy-plenum 포함)와 함께 패키지를 복사
• [indy-node] rc 채널에 대한 시스템 테스트를 실행
• release-X.Y.Z(release commit을 가리키는 포인트) 브랜치에서 stable로 release PR을 생성
• maintainer에게 알림
• 승인이 진행될 때까지 대기. release PR이 필요한 모든 검사를 통과할 때까지 제공해서는 안됩니다(예: DCO, CI 테스트, maintainers 검토 등).

3. [build server]

• PR에 CI를 실행하고 GitHub에 알림

4. [QA]

• (선택 사항) 추가 테스트 수행

5. [Maintainer]

• PR을 검토하지만 merge하지 마십시오.
• 승인된 경우: 진행할 서버를 구축
• 그렇지 않은 경우: 파이프 라인을 중지

6. [build server]

• 승인된 경우:
  • fast-forward merge 수행
  • vX.Y.Z 태그 생성 및 push;
  • maintainer에게 알림
• 그렇지 않은 경우 release-X.Y.Z를 상위로 이동하여 release commit 롤백

 

3. Publishing

1. release PR이 merge되면 [build server] 트리거

• X.Y.Z로 PyPI에 게시
• debian 패키지 X.Y.Z~rcN(rc-latest 채널에서)을 패키지 이름만 변경하여 X.Y.Z로 다운로드하고 다시 압축
• 패키지를 rc-latest debian 채널에 게시
• rc-latest에서 stable-latest 채널로 dependency와 함께 패키지를 복사
• [indy-node] stable-latest 버전에서 stable 채널로 패키지(indy-plenum 포함)와 함께 패키지를 복사
• [indy-node] stable 채널에 대한 시스템 테스트 실행
• maintainer에게 알림

 

4. New Development Cycle Start(새로운 개발 사이클 시작)

1. [Contributor]:

• X'.Y'.Z'.dev0로 bump할 버전과 함께 mater에 PR 생성. 여기서 X'.Y'.Z'는 다음 tartget release 버전입니다. 일반적으로 X,Y 또는 Z 중 하나를 증가시키고 더 낮은 부분을 재설정합니다(자세한 내용은 SemVer를 확인하십시오) 예:
  • X.Y.Z+1 - 버그 수정 릴리즈
  • X.Y+1.0 - 기능 릴리즈, 이전 버전과 호환되는 API 추가/변경
  • X+1.0.0 - 주요 릴리즈, 이전 버전과 호환되지 않는 API 변경

 

Hotfix Release(Hotfix 릴리즈)

Hotfix 릴리즈는 다음 차이점을 제외하고는 매우 유사합니다:

• 이름이 hotfix-X.Y.Z인 hotfix 브랜치;
• 일반적으로 hotfix는 stable 코드에 대한 수정 사항만 포함해야하므로 master는 일반적으로 merge되지 않습니다.