티스토리 뷰

Blockchain/Hyperledger Indy

[Hyperledger Indy Docs] Indy SDK: 9. Contributing

miiingo 2020. 2. 10. 18:07
반응형

원본 사이트 : https://hyperledger-indy.readthedocs.io/projects/sdk/en/latest/docs/contributors/index.html

MAINTAINERS 파일을 검토하십시오.

그런 다음 아래의 문서를 숙지하십시오.

 

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

원본 사이트 : https://hyperledger-indy.readthedocs.io/projects/sdk/en/latest/docs/contributors/release-workflow.html#

 

Indy SDK components(Indy SDK 구성 요소)

Indy SDK에는 다음과 같은 구성 요소가 전용 패키지로 관리됩니다.

  • Libindy
  • Wrappers for programming languages:
    • Python
    • Java
    • ObjectiveC (iOS)
    • .Net
  • Indy CLI

 

Release artifacts(아티팩트 릴리즈)

Indy SDK 릴리즈 프로세스는 구성 요소에 대해 다음 아티팩트를 생성합니다.:

  • Libindy
    • 우분투 deb 패키지. https://repo.sovrin.org/sdk/lib/apt/xenial/{master|stable|rc}/libindy_{version}.deb에서 사용 가능
    • 종속성이 있는 zip-archive의 Windows 바이너리. https://repo.sovrin.org/windows/libindy/{master,stable,rc}/{version}/libindy_{version}.zip에서 사용 가능
    • iOS Cocoapods 패키지. https://repo.sovrin.org/ios/libindy/{master|stable}/libindy-core/{version}/libindy.tar.gz에서 사용 가능. 현재 CD 파이프 라인은 지원되지 않지만 주기적으로 수동 빌드를 수행합니다.
    • MacOS 바이너리는 계획되었지만 CD 파이프 라인에서는 현재 지원되지 않습니다.
    • RHEL 바이너리는 계획되었지만 CD 파이프 라인에서는 현재 지원되지 않습니다.
  • 프로그래밍 언어용 wrapper
    • Python wrapper인 PyPy 패키지. PyPi에서 python3-indy 패키지로 제공됩니다.
    • Java wrapper인 maven 패키지. https://repo.sovrin.org/repository/maven-public maven repo에서 org.hyperledger/indy 패키지로 제공됩니다.
    • ObjectiveC (iOS) Cocoapods 패키지. https://repo.sovrin.org/ios/libindy/{master|stable}/libindy-objc/{version}/libindy-objc.tar.gz에서 사용 가능
    • .Net. 패키지가 계획되었지만 현재 CD 파이프 라인에서 지원되지 않습니다.
  • Indy CLI tool
    • 우분투 deb 패키지. https://repo.sovrin.org/sdk/lib/apt/xenial/{master|stable|rc}/indy-cli_{version}.deb에서 사용 가능
    • 종속성이 있는 zip-archive의 Windows 바이너리. https://repo.sovrin.org/windows/indy-cli/{master,stable,rc}/{version}/indy-cli_{version}.zip에서 사용 가능
    • MacOS 바이너리는 계획되었지만 CD 파이프 라인에서는 현재 지원되지 않습니다.
    • RHEL 바이너리는 계획되었지만 CD 파이프 라인에서는 현재 지원되지 않습니다.

 

Release channels(릴리즈 채널)

Indy SDK 릴리즈 프로세스는 다음 릴리즈 채널을 정의합니다.

  • master - 마스터 브랜치로 push할 때마다 개발 빌드
  • rc - 릴리즈 후보
  • stable - 안정적인 릴리즈. 이 채널은 브랜치와 정확히 일치하지 않습니다. 안정적인 채널은 rc 브랜치의 태그입니다. 앞으로는 변경될 수 있습니다.

 

Compatibility with indy-node(indy-node와의 호환성)

릴리즈와 관련하여 indy-sdk와 indy-node의 관계를 이해하는 것이 중요합니다. SDK는 일반적으로 indy-node와 거의 같은 시간에 새로운 기능을 추가하는데 중점을 두고 있으며, 새로운 기능이 새로 진화된 원장의 해당 기능과 작동하는지 입증하기 위해 대부분의 호환성 테스트 노력을 기울입니다. 때때로 원장이 변경되지 않고 SDK가 버그 수정과 함께 릴리즈 될 수도 있지만 이러한 흐름은 덜 인반적입니다. 이러한 이유로 가장 중요한 릴리즈 순서는 원장(indy-node)에 새로운 기능이 제공되고 SDK는 곧 새로운 기능을 제공하게 됩니다. SDK는 원장이 노출하는 새로운 기능과 호환됨을 증명해야합니다.

따라서 SDK의 마스터 브랜치는 indy-node의 최신 stable 빌드 또는 최신(최신 또는 최신에 가까운) master 빌드에 의존할 수 있습니다. 즉, indy-sdk 소비자는 최신 master 빌드를 사용하는 것이 좋지 않습니다. 이 빌드는 현재 안정적인 프로덕션 환경에 있는 indy-node 버전과 호환되지 않을 수 있기 때문입니다. 위험 부담을 가지고 indy-sdk의 master 브랜치를 사용하십시오.

 

Versioning(버전 관리)

  • 모든 구성 요수는 항상 함께 릴리즈되며 단순성을 위해 동일한 버전이 있습니다. 나중에 변경될 수 있습니다.
  • 버전의 형식은 {major}.{minor}.{patch}입니다. 우리는 Semver 규칙을 따를 계획이지만 주요 버전이 너무 많이 증가하는 것을 피하기 위해 첫 번째 릴리즈에는 예외가 있습니다.
  • RC 빌드에는 빌드를 안정시킨 후 제거될 rc 번호 접미사(suffix)가 있습니다.
  • Master 빌드에는 빌드 번호 접미사(suffix)가 포함된 최신 stable 릴리즈 버전이 있습니다. master 빌드는 Semver를 따르지 않습니다. 버전은 rc 생성의 순간에 수행된 Semver에 따라 증가합니다.
  • Indy CLI 및 wrapper는 libindy에 따라 다릅니다. 간단하게 하기 위해 구성 요소 릴리즈 중에 생성된 정확한 libindy 버전을 사용하여 이 종속성을 설명합니다. 앞으로 강력한 Semver로 전환한 후에는 Semver를 기반으로 하는 libindy에 덜 의존적으로 사용할 수 있습니다.

 

CI/CD pipelines(CI/CD 파이프 라인)

결정적인 CI/CD 파이프 라인으로 빌드 생성이 자동화됩니다.

 

Releases process(릴리즈 프로세스)

  • 팀은 GitHub 플로우 프로세스를 두 가지 주요 브랜치와 함께 사용합니다.
    • master - 개발 브랜치
    • rc - 릴리즈 후보 브랜치. 릴리즈 후보 중 일부는 stable이 될 것입니다.
  • 개발은 master 브랜치로 PR이 상승하는 GitHub 포크에서 수행됩니다.
  • master 브랜치에 대한 각 PR에 대해 팀은 코드 검토를 수행하고 CI 파이프 라인은 모든 구성 요소에 대한 단위 및 통합 테스트를 실행합니다. 병합(merge)은 모든 테스트가 master 브랜치에 병합되는 동일한 커밋을 통과한 경우에만 사용할 수 있습니다.
  • master CD 파이프 라인으로 PR 병합 후 병합 커밋에서 실행됩니다. master 채널의 빌드 번호 접미사(suffix)가 증가하여 테스트를 실행하고 새 패키지를 빌드합니다.
  • 릴리즈를 수행하기로 결정한 경우:
    • master 브랜치 포크
    • 변경 사항 분석
    • 모든 구성 요소에 대한 증분 버전. 이 구성 요소에 변경 사항이 없더라도 버전(적어도 패치)은 항상 증가합니다.
    • 릴리즈 정보 업데이트
    • PR(master + 버전 변경)을 rc 브랜치로 상승
  • rc의 각 PR에 대해 팀은 코드 리뷰를 수행하고 CI 파이프 라인은 모든 구성 요소에 대한 단위 및 통합 테스트를 실행합니다. 병합은 모든 테스트가 rc에 병합될 동일한 커밋을 통과한 경우에만 사용할 수 있습니다.
  • rc에 PR이 병합된 후에 CD 파이프 라인은 병합 커밋에서 실행됩니다. 테스트를 실행하고 rc 채널의 rc 번호 접미사(suffix)가 증가하여 새 패키지를 빌드합니다. 이 CD 파이프 라인이 일시 정지된 후 승인이 완료될 때까지 기다리십시오.
  • 팀은 릴리즈 채널에서 작성된 아티팩트를 사용하여 승인 테스트를 실행합니다.
  • 문제가 발견되지 않으면 팀이 릴리즈를 승인합니다. CD 파이프 라인이 재개되고 아티팩트를 안정적인 릴리즈 채널로 이동하고 해당 커밋에서 Git 릴리즈 태그를 만듭니다.
  • 일부 문제가 발견되면 팀은 릴리즈를 거부하고 rc 브랜치에 대한 hot-fix PR 작성을 시작합니다. PR이 작성된 후 릴리즈 프로세스는 rc PR 단계에서 재개됩니다.
  • 릴리즈가 수행된 후에 팀은 rc 브랜치를 master 브랜치에 병합합니다.

 

Signing Commits(커밋 서명)

원본 사이트 : https://hyperledger-indy.readthedocs.io/projects/sdk/en/latest/docs/contributors/signing-commits.html

커밋에 서명하지 않아서 여기 있다면 두려워하지 마십시오. 이전 커밋에 서명하는 방법을 확인하십시오.

우리는 모든 하이퍼레저 저장소에서 개발자의 origin 증명서(DCO: Developer Certificate of Origin)를 사용하므로 pull 요청을 수락하려면 커밋마다 서명하여 커밋을 인증해야합니다.

 

Signing your current commit(현재 커밋에 서명)

  • $ git commit -s -m "your commit message"
  • 커밋이 서명되었는지 확인하려면 $ git log --show-signature를 실행하십시오.
  • 최신 커밋을 다시 서명해야하는 경우 $ git commit --amend --no-edit -s를 사용하십시오.

-s 플래그는 사용자의 이름과 이메일로 커밋 메시지에 서명합니다.

 

How to Sign Previous Commits(이전 커밋에 서명하는 방법)

  1. git log --show-signature를 사용하여 어떤 커밋에 서명해야하는지 확인하십시오.
  2. $ git rebase -i HEAD~X를 사용하여 대화식 리베이스 모드로 들어가십시오. 여기서 X는 보고자하는 최신 커밋까지의 커밋 수입니다.
  3. 텍스트 파일에 커밋 목록이 표시됩니다. 서명을 해야하는 각 커밋 뒤의 라인에 소문자 -s와 함께 exec git commit --amend --no-edit -s를 추가하고 커밋 본문에 텍스트 서명을 추가하십시오. 두 커밋에 서명하는 예:
pick 12345 commit message
exec git commit --amend --no-edit -s
pick 67890 commit message
exec git commit --amend --no-edit -s

1. 이전 커밋을 한 번에 다시 서명해야하는 경우, git log --show-signature를 사용하여 서명되지 않은 가장 빠른 커밋을 찾아서 다음 명령에서 커밋의 HASH를 사용하십시오.: git rebase --exec 'git commit --amend --no-edit -n -s' -i HASH. 이것은 가장 최근부터 HASH 직전의 모든 커밋에 서명합니다.

2. 서명되지 않은 커밋을 원격으로 push한 경우 git push -f를 사용해 강제로 push해야합니다.

 

Test Design(테스트 디자인)

원본 사이트 : https://hyperledger-indy.readthedocs.io/projects/sdk/en/latest/docs/contributors/test-design.html

 

Components(구성 요소)

Indy SDK에는 다음과 같은 부분이 포함되어 있습니다.:

  • libindy - Sovrin 기반 애플리케이션 개발을 위한 고급 API를 제공하는 기본 라이브러리. Indy pool과의 통신 처리, 보안 wallet, agent 통신, 서명/검증, 암호화/암호해독 및 anoncreds 프로토콜
  • Python Wrapper - Python 언어로 애플리케이션 개발을 허용하는 네이티브 libindy용 FFI 기반 wrapper
  • Java Wrapper - Java 플랫폼에서 애플리케이션 개발을 허용하는 네이티브 libindy용 FFI 기반 wrapper
  • iOS Wrapper - Java 플랫폼에서 애플리케이션 개발을 허용하는 네이티브 libindy용 Objective-C 기반 wrapper
  • .Net Wrapper - .Net 플랫폼에서 애플리케이션 개발을 허용하는 네이티브 libindy용 FFI 기반 wrapper

 

Acceptance testing(수락 테스트)

수락 테스트 절차는 다음과 같은 부분으로 구성됩니다.

  • 기능 테스트
  • 설치성 테스트
  • 상호 운용성 테스트
  • 문서화 테스트

 

Functional testing(기능 테스트)

테스트 절차의 기능 부분에는 master 또는 rc 브랜치에 대한 각 병합 커밋에 대해 CI/CD가 실행하는 일련의 자동화된 시스템/통합 테스트가 포함됩니다. 릴리즈 아티팩트는 테스트 실행에 사용된 동일한 libindy 바이너리에서 작성됩니다. rc 패키지 작성은 자동화된 기능 테스트가 통과되었다고 가정합니다. 자세한 내용은 cd-pipeline.puml을 참조하십시오.

libindy와 wrapper는 단위 테스트 세트도 제공하지만 TDD 방식을 따르고 공식적인 테스트 디자인을 따르지 않는 데 주로 사용됩니다.

앞으로 우리는 rc 패키지가 생성된 후에 수행될 복잡한 경우에 대한 몇 가지 수동 단계로 기능 테스트 절차를 확장할 것으로 예상합니다. 주로 Low case와 관련이 있습니다.

 

Functional specification(기능 사양)

API 호출 사양은 소스 코드의 인터페이스 부분에 주석으로 표시됩니다. 참고:

 

Test groups(테스트 그룹)

우선 순위별로 다음 테스트 그룹을 정의합니다.

  • High cases
  • Medium cases
  • Low cases

 

High cases

High case 테스트를 성공적으로 완료하면 Alpha 품질이 나타납니다.

  • 정상적인 경우. 여러 실행 브랜치가 있을 수 있습니다. 우리는 각 브랜치에서 커버해야합니다. 브랜치 예:
    • 엔티티는 wallet에서 캐시됩니다.
    • 엔티티는 원장에서 가져와야합니다.
  • 명시적인 복구 절차가 필요한 오류 사례. 예:
    • Invalid wallet credentials(잘못된 wallet credentials)
    • No entity found in the wallet(wallet에 엔티티가 없습니다.)
    • No entity found in the ledger(원장에 엔티티가 없습니다.)
    • Transaction doesn’t allow for current identity(트랜잭션에서 현재 identity를 허용하지 않습니다.)
    • Unknown crypto(알 수 없는 암호화(
    • Claim doesn’t correspond to scheme, proof request doesn’t correspond to claim and etc…(Claim이 schema와 일치하지 않으며 proof request가 claim과 일치하지 않습니다.)
    • Revocation registry is full and etc…(해지 레지스트리가 가득 찼습니다.)

 

Medium cases

High 및 Medium case 테스트를 성공적으로 완료하면 Beta 품질이 나타납니다.

  • 전제 조건 체크:
    • Invalid handle(잘못된 처리)
    • Wallet doesn’t correspond to pool(wallet이 pool에 해당하지 않습니다.)
    • Invalid json format(잘못된 JSON 형식)
    • Invalid json structure (missed fields and etc…) (유효하지 않은 JSON 구조(필드 누락 등))
    • Invalid base58 (잘못된 base58)
    • Invalid crypto keys length and format (유효하지 않은 암호화 키 길이 및 형식)
    • Invalid crypto primitives (bigints, points) (유효하지 않은 암호화 기본 요소(bigints, points))
    • Invalid complex crypto structures (anoncreds structures mostly) (유효하지 않은 복잡한 암호화 구조(주로 anoncreds 구조))
    • Invalid responses from 3d parties (Ledger, Agent) (제3자(원장, Agent)의 잘못된 응답)

 

Low cases

High, Medium 및 Low case 테스트를 성공적으로 완료하면 Production 품질이 나타납니다.

  • 테스트하기 어려운 경우: Io 오류, timeout 등

 

Tests specification(테스트 사양)

테스트 사양은 API 그룹, API 호출, 테스트 레벨별로 그룹화된 코드의 각 API 호출에 대한 테스트 케이스 목록으로 제공됩니다. 또한 주로 사용 예제를 제공하기 위한 전용 "demo" 테스트가 있습니다.

현재로서는 libindy에 대해 High 및 Medium case를 구현했습니다(Anoncreds의 해지 부분 제외). Python, Java, iOs 및 .Net wrapper에 대한 High case

wrapper에 대한 High case에는 libindy와 동일한 테스트가 포함되어 있으며 이 테스트 케이스를 동기화된 상태로 유지합니다. wrapper의 아키텍처는 Beta+ 품질에 대해 High case 적용 범위로 충분할 수 있다고 주장할 수 있습니다.

테스트 절차는 개발자(전문 QA가 아님)가 작성했으며 검토 및 개선이 필요할 수 있습니다.

보기:

 

Installability testing(설치성 테스트)

기능성 테스트는 아티팩트 패키징 전에 수행됩니다. libindy는 약간의 런타임 의존성을 가지고 있으며 패키지 설치가 이러한 의존성을 만족시켜야 합니다.

나는 다음을 제안합니다.:

  • libindy 아티팩트에 의존하는 C, Python 및 Java에서 간단한 데모 프로젝트를 작성하고 데모 테스트를 이러한 프로젝트로 옮깁니다(향후 iOS, .Net 및 NodeJS용 프로젝트가 필요함). 현재 스프린트(sprint)에서 이 작업을 시도할 수 있습니다.
  • Ubundu와 Windows에서 libindy와 wrapper 설치를 테스트합니다(추후에 MacOS와 RHEL, iOS에서도 테스트)
  • 이 데모 프로젝트를 rc 패키지로 빌드하고 실행할 수 있는지 테스트합니다.

첫 번째 릴리즈의 경우 이 단계는 향후 수동 및 자동화로 실행될 수 있습니다.

 

Ubuntu testing(Ubuntu 테스트)

  • pool 실행(Ubuntu readme의 docker 네트워크 옵션 참조)
  • Docker 이미지 빌드 : docker build -f ubuntu_acceptance.dockerfile --build-arg indy_sdk_deb="URL to download appropriate version of libindy.deb"
  • 이전 단계에서 빌드된 Docker 이미지에서 Docker 컨테이너 시작 : docker run -it -v <path/to/indy-sdk/samples>:/home/indy --network=<pool network name> <Image ID> /bin/bash
  • Docker 컨테이너 내에서:
    • Java wrapper 확인
      • cd java
      • pom.xml에 indy 의존성 버전 설정
      • TEST_POOL_IP=<pool ip> mvn clean compile exec:java -Dexec.mainClass="Main"
      • 결과 확인
      • cd ..
    • Python wrapper 확인
      • cd python
      • setup.py에 python3-indy 의존성 버전 설정
      • python3.6 -m pip install -e .
      • TEST_POOL_IP=<pool ip> python3.6 src/main.py

 

Interoperability testing(상호 운용성 테스트)

Interoperability testing(상호 운용성 테스트)

다음과 같은 상호 윤용성 사례가 필요합니다.

  • libindy - Node
    • 최신 노드 버전과 상호 운용성. 우리는 이미 기능 테스트로 테스트했습니다.
    • 노드의 하위 호환성은 Indy Node compatibility의 일부로 테스트됩니다. (호환성이 indy-node 및 indy-sdk의 브랜치와 관련되는 방법에 대한 설명은 이 참고사항을 참조하십시오.)
  • libindy - pyindy:
    • Anoncreds 프로토콜 상호 운용성. 기능 테스트의 일부로 이미 구현되었습니다.
  • libindy - libindy
    • 주 버전에 대한 지속적인 configuration 이전 버전과의 호환성(테스트 개발 필요, IS-312).
    • 주 버전에 대한 지속적인 wallet 이전 버전과의 호환성(테스트 개발 필요, IS-312).
    • 주 버전에 대한 지속적인 pool 캐시 이전 버전과의 호환성(테스트 개발 필요, IS-312).
    • 주 버전에 대한 Anoncreds 프로토콜 이전 버전과의 호환성(테스트 개발 필요, IS-312).
    • 주 버전에 대한 Agent 통신 이전 버전과의 호환성(테스트 개발 필요, IS-312).
  • libindy - wrappers
    • 첫 번째 릴리즈의 경우 wrapper를 동일한 패키지로 릴리즈하고 정확한 버전 상호 운용성만 요구합니다. 현재 기능 테스트 절차는 wrapper 기능 테스트와 이 상호 운용성 검사를 수행합니다.

첫 번째 릴리즈에서는 기존 기능 테스트로 이동할 수 있지만 향후 릴리즈에서는 전용 상호 운용성 테스트를 만들어야합니다. 이러한 테스트는 자동화할 수 있습니다.

 

Documentation testing(문서화 테스트)

  • 변경 내용 검증
  • 청구된 모든 변경 사항에 대한 문서 업데이트 검증
반응형
저작자표시 비영리 동일조건

'Blockchain > Hyperledger Indy' 카테고리의 다른 글

[Hyperledger Indy Docs] Indy Node: 2. Requests  (0) 2020.02.19
[Hyperledger Indy Docs] Indy Node: 1. Transactions  (0) 2020.02.19
[Hyperledger Indy Docs] Indy SDK: 8. Design Documents  (0) 2020.02.10
[Hyperledger Indy Docs] Indy SDK: 4. Building Indy SDK  (1) 2020.02.10
[Hyperledger Indy Docs] Indy SDK: How Tos  (0) 2020.02.10
댓글
반응형
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
TAG more
«   2024/05   »
일 월 화 수 목 금 토
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
글 보관함