Monorepos의 연속 포인트

Monorepos는 많은 프로젝트의 고도를 뛰어넘는 활발한 코드 라이브러리다.이것들은 전통적인 연속 포인트의 한계성을 시험할 수 있다.Semaphore는 Monorepos에 기존 지원을 제공하는 유일한 CI/CD입니다.

Monorepo 워크플로우는 쉽게 설정할 수 있어야 합니다.

Amonorepo는 개별 개발자 또는 팀이 관리하는 여러 프로젝트를 포함하는 저장소입니다.대부분의 경우 이러한 코드 라이브러리는 독립적이지만 하나의 공공 저장소CI/CD workflow를 공유한다.
Monorepos의 워크플로우는 자신만의 다양한 과제를 제시합니다.기본적으로 CI/CDpipeline는 커밋할 때마다 처음부터 끝까지 실행됩니다.이것은 예상했던 것이다.어쨌든, 이것은 continuous integration 중의 연속성이다.

하나의 프로젝트 저장소에서 파이프를 실행하는 모든 작업은 논리에 완전히 부합된다.하지만 monorepos의 활동은 평소보다 훨씬 많다.최소한의 변화라도 전체 파이프를 다시 운행할 것이다. 이것은 시간도 소모되고 비싸다.이것은 근본적으로 말이 안 된다.
신호량recently introduced 함수change_in.따라서 변경에 기반한 실행 능력을 증가시켰다.변경 조건을 사용하면 관련 코드가 업데이트되지 않았을 때 작업을 건너뛸 수 있습니다.이것은 파이프에서 다시 운행하고 싶지 않은 부분을 무시하게 할 것이다.

monorepo 작업 흐름을 어떻게 설정합니까

이 절에서, 우리는monorepo 파이프를 세울 것이다.semaphore-demo-monorepo 프로젝트를 시작으로 하지만 이 단계를 신호량의 모든 CI/CD 워크플로우로 조정할 수 있습니다.
이 설명서를 따르려면 다음이 필요합니다.

GitHub 계정.

계좌 하나Semaphore.GitHub 등록을 클릭하여 무료 평가판 계정을 만듭니다.

계속, GitHub에 갈라짐repository.각 항목은 별도의 폴더에 있는 세 개의 항목으로 구성됩니다.

/service/billing: Go로 작성하여 사용자 지불을 계산한다.

/service/user: Ruby 기반 사용자 등록 서비스HTTP REST 끝점을 공개합니다.

/service/ui: 웹 UI 구성 요소입니다.불로장생의 약으로 썼다.

이 모든 부분은 협동 작업을 위한 것이지만, 각 부분은 단독 팀에서 유지하고, 서로 다른 언어로 작성될 수 있다.
그런 다음 신호등 계정을 사용하여 로그인하고 왼쪽 상단의 "새로 만들기"를 클릭합니다.

이제 갈라진 저장소를 선택하십시오.

이 때 프로젝트에 인원을 추가할 수 있습니다.작업을 마치면 [계속]을 클릭하고 [처음부터 프로젝트를 구성하고 싶습니다]를 선택합니다.

요금 계산 프로그램부터 시작하겠습니다.Go starter 워크플로우를 찾아 사용자 정의를 클릭합니다.

작업을 수행하기 전에 작업을 수정해야 합니다.

Chargeback 애플리케이션은 Go 버전 1.12를 사용합니다.따라서 첫 번째 행을 sem-version go 1.12로 변경합니다.

코드는 services/billing 폴더에 위치하고 cd services/billing 다음에 checkout를 추가합니다.

전체 작업은 다음과 같아야 한다.

sem-version go 1.12
export GO111MODULE=on
export GOPATH=~/go
export PATH=/home/semaphore/go/bin:$PATH
checkout
cd services/billing
go get ./...
go test ./...
go build -v .

지금 작업 흐름을 실행하려면 누르십시오.Branch에서 Master를 입력하고 Start를 클릭합니다.정확한 지점을 선택하는 것은 제출한 계산 방식에 영향을 줄 수 있기 때문에 매우 중요하다.우리 잠시 후에 다시 이야기합시다.

신호량은 응용 프로그램을 구축하고 테스트하기 시작해야 한다.

파이프에 두 번째 프로그램을 추가합니다.편집기를 열려면 오른쪽 상단의 워크플로 편집을 클릭합니다.

새 블록을 추가합니다.그런 다음 Ruby 애플리케이션을 설치하고 테스트하는 명령을 추가합니다.

sem-version ruby 2.5
checkout
cd services/users
cache restore
bundle install
cache store
bundle exec ruby test.rb

종속성 아래의 모든 확인란을 선택 취소합니다.

세 번째 블록을 추가하여 UI 서비스를 테스트합니다.다음은 이 프로그램을 설치하고 테스트할 것입니다.모든 블록 의존 항목을 선택 취소하는 것을 기억하십시오.

checkout
cd services/ui
sem-version elixir 1.9
cache restore
mix local.hex --force
mix local.rebar --force
mix deps.get
mix deps.compile
cache store
mix test

지금 우리가 /services/ui 폴더의 파일을 바꾸면 무슨 일이 일어날지 알아맞힐 수 있습니까?

네, 한 항목만 바뀌었지만 모든 모듈이 실행 중입니다.이것은 가장 좋은 것이 아니다.수백 개의 프로젝트를 가진 대형 모노레포는 대량의 CPU 주기를 낭비하는 과정이라고 상상할 수 있다.좋은 소식은 변경에 기반한 실행을 시도하기에 매우 적합하다는 것이다.

변경 기반 실행

change_in 함수는 최근 제출이 주어진 파일이나 폴더의 코드를 변경했는지 계산합니다.우리는 블록 단계에서 이 함수를 호출해야 한다.변경 사항이 감지되면 블록의 모든 작업이 수행됩니다.그렇지 않으면 전체 블록이 건너뜁니다.change_in 특정 블록을 저장소 섹션에 바인딩할 수 있습니다.
우리는 건너뛰기/실행 조건 부분을 열고 "조건이 충족될 때 이 블록을 실행합니다"라는 옵션을 사용해서 모든 블록에서 이 함수를 호출할 수 있습니다.

이 기능의 기본 용도는 다음과 같습니다.

change_in('/web/')

web 폴더의 파일이 변경되면 블록이 실행됩니다.절대 경로는 /로 시작하고 저장소의 루트를 참조합니다.상대 경로는 슬래시로 시작하지 않으며 파이프 파일을 기준으로 하며 파이프 파일은 /.semaphore 폴더에 있습니다.
또한 특정 파일에 대해서도 다음을 수행할 수 있습니다.

change_in('../package-lock.json')

와일드카드도 지원됩니다.

change_in('/**/package.json')

또한 하나의 경로만 감시하는 것이 아니라 파일이나 폴더의 목록을 정의할 수 있습니다.예를 들어, /web/ 폴더 또는 /manifests/kubernetes.yml 파일 변경(둘 다 작업 변경) 시 이 블록이 실행됩니다.

change_in(['/web/', '/manifests/kubernetes.yml'])

함수는 두 번째 선택할 수 있는 매개 변수를 사용하여 동작을 변경할 수 있습니다.예를 들어, 저장소의 기본 브랜치가 main가 아닌 masterGitHub’s new default인 경우 추가default_branch: 'main'해야 합니다.

change_in('/web/', { default_branch: 'main' })

우리가 파이프를 업데이트할 때, 신호량은 모든 작업을 다시 실행할 것이다.pipeline_file: 'ignore'를 사용하여 비활성화할 수 있습니다.

change_in('/web/', { pipeline_file: 'ignore' })

또 다른 유용한 옵션은 exclude입니다. 파일이나 폴더를 무시할 수 있습니다.또한 와일드카드를 지원합니다.예를 들어, 모든 태그 파일을 무시하려면 다음과 같이 하십시오.

change_in('/web/', { exclude: '/web/**/*.md' })

나머지 옵션을 보려면 conditions YAML reference를 참조하십시오.

시장 변화에 따라 파이프 건설을 가속화하다

change_in가 어떻게 파이프의 속도를 높일 수 있는지 봅시다.
워크플로우 편집기를 다시 엽니다.블록 중 하나를 선택하고 [건너뛰기/실행 조건] 섹션을 엽니다.몇 가지 변경 기준을 추가합니다.

change_in('/services/billing')

나머지 블록에 대해 이 단계를 반복합니다.

change_in('/services/ui')

다음을 포함합니다.

change_in('/services/users')

파이프를 다시 실행합니다.네가 알아차릴 수 있는 첫 번째 일은 새로운 초기화 절차가 있다는 것이다.여기서 신호량 계산의 차이는 어떤 블록을 운행해야 하는지를 결정한다.너는 일지를 보고 배후에서 무슨 일이 일어났는지 볼 수 있다.
작업 흐름이 완료되면 신호량은 모든 작업을 다시 시작합니다. (이것은 우리가 설정하지 않았기 때문입니다. pipeline_file: 'ignore'우리가 그 중 한 프로그램에서 파일을 바꾸었을 때, 재미있는 점이 나타났다.일은 바로 이렇다.

너는 내가 어떤 응용 프로그램을 바꿨는지 알아맞힐 수 있니?네, 맞아요.나는 요금 계산 프로그램에 파일을 추가했다.따라서 change_in 때문에 나머지 블록은 변경 조건에 부합되지 않기 때문에 건너뛰었다.
만약 우리가 감시를 받는 폴더 밖에서 변경을 한다면 모든 블록은 건너뛰고 파이프는 몇 초 안에 완성될 것이다.

제출 범위 계산

어떤 블록이 실행될지 이해하기 위해서, 우리는 change_in 최근에 제출한 변경된 파일을 어떻게 계산하는지 식별해야 한다.제출 범위는 당신이 처리 중main/master인지 테마 지점에 따라 결정됩니다.
주 지점에 대해 신호량이 전송된 모든 제출 중의 변경 사항을 비교한 다음 최소한 일치하는 항목이 없는 change_in 블록을 건너뜁니다.

신호량은 지점에 대해 더욱 광범위한 표준을 채택한다.제출 범위는 첫 번째 제출 지점에서 지점의 머리까지.이것은 신호량이 변경 기준에 부합되지 않는 제출에서도 블록을 다시 실행할 수 있다는 것을 의미한다.

요청을 끄는 행위는 유사하다.제출 범위는 첫 번째 제출부터 정의되며, 첫 번째 제출은 지점 헤더에 통합될 지점에서 시작됩니다.

변화에 기반한 자동 프로모션

우리는 또한 autopromotions에서 change_in를 사용할 수 있다. 그러면 우리는 특정 조건하에서 자동으로 추가 파이프를 가동할 수 있다.
새 파이프라인을 생성하려면 워크플로우 편집기를 다시 열고 첫 번째 업그레이드 추가를 클릭합니다.

자동 업그레이드 사용 을 선택합니다.시작점으로 사용할 수 있는 예시적인 부분을 보셔야 합니다.

모든 작업이 기본 분기를 통과할 때 change_in 와 branch = 'master' AND result = 'passed' 를 조합해서 파이프를 시작할 수 있습니다.

change_in('/services/billing/') and branch = 'master' AND result = 'passed'

완료되면 워크플로를 실행하여 변경 사항을 저장합니다.지금부터 요금 계산 프로그램을 변경할 때 모든 테스트가 통과되면 새 파이프가 자동으로 시작됩니다. master

change 의 기술 활용

코드 및 파이핑을 구성하는 방법은 다음과 같습니다change_in. 대규모 MonoRepo를 확장하는 것이 더 쉽습니다.

깨끗한 변경 조건을 사용할 수 있도록 통일된 폴더 조직을 정의합니다.

프로젝트 폴더를 중심으로 블록을 설계합니다.

필요할 때 여러 개의 파일과 폴더를 change_in에 추가합니다.이 옵션을 사용하면 monorepo에 연결된 모든 항목 구성 요소를 재구성할 수 있습니다.

분기를 작게 유지하고 자주 통합하여 구축 시간을 단축합니다.

및 와일드카드를 사용하여 관련 없는 파일(예: 문서 또는 읽어쓰기)을 무시합니다.

자동차 판촉에 사용exclude하고 연속적인 납품 또는 배치 파이프를 선택적으로 촉발한다.

Monorepo의 작업 흐름이 훨씬 빨라요.

우리는 신호량의 특성을 가장 잘 이용하여 monorepos에서 CI/CD 파이프를 실행하는 방법을 배웠다.change_in 함수를 사용하면 테스트된 코드를 재구성하는 데 시간을 낭비하지 않고 더 빠른 파이프를 설계할 수 있습니다.
monorepo CI/CD 워크플로우에 대한 자세한 내용:

What is monorepo?

Monorepo workflows

Change_in reference page