5+1 리모델링 로봇의 소음을 줄이는 팁

간단한 소개

소프트웨어 엔지니어로서, 우리는 자동화 작업을 좋아한다. 특히 임무가 중복되고 지루한 상황에서.자동 의존 항목 업데이트가 바로 이런 작업의 좋은 예이다.
다행히도, 우리는 자신의 해결 방안을 개발할 필요가 없다. 왜냐하면 시장에 여러 개의 (무료 사용) 로봇이 있기 때문이다.가장 인기 있는 것은 Greenkeeper, Dependabot(GitHub에 통합됨) 및 Renovate Bot입니다.
나는 개인적으로 리모델링을 가장 좋아한다. 왜냐하면 그것은 대량의 기능과 배치 능력을 가지고 있기 때문이다.첫 번째 측면에서 볼 때 이 로봇들은 강력하고 도움이 되지만, 우리는 곧 그것들이 발생하는 소음에 잠길 것이다.또한 CI 시스템은 과중한 부하를 처리해야 합니다.
현재 저장소의 최신 버전Onboarding PR만 확인하면 됩니다.아직 젊지만 리네이브는 27개(!)를 만들고 싶어한다.PRs 지금:

나에게 있어서, 분명히 우리는 자동화를 더욱 잘 제어할 수 있는 전략을 생각해 내야 한다.Revolve도 이 문제를 인식하고 그들의 문서 페이지에 약간의 useful tips 를 제공했다.아래의 5+1 기교는 Refroves 문서와 제가 회사에서 Nx를 바탕으로 하는 monorepository에서 Refrove를 실행한 실천 경험을 바탕으로 합니다.

1. 팁: 패키지 그룹 구성

나에게 있어서 첫 번째 건의는 가장 뚜렷하지만 가장 강력한 리모델링 설정 옵션이다. Package Grouping
REFRONE을 사용하고 확장config:base 프리셋을 사용하기 시작하면 기본 설정 자체group:monorepos 프리셋이 포함되어 있기 때문에 이 기능을 사용합니다.이 규칙 세트에는 단일 저장소에 있는 여러 패키지의 종속성 업데이트를 하나의 PR에 그룹화하는 논리도 포함됩니다.Here 지원되는 모든 패키지를 볼 수 있습니다.가장 유명한 것은 당연히 @angular/* 또는 react 가방이다.
이러한 논리를 확장하려면 자신의 그룹을 만들기만 하면 됩니다.

{
  "packageRules": [
    {
      "matchPackagePatterns": ["eslint"],
      "groupName": "eslint"
    }
  ]
}

이 기능이 이렇게 강한 이유는 PRs의 수를 쉽게 줄일 수 있을 뿐만 아니라 다른 그룹에서 완전히 다른 전략을 사용할 때 특정 그룹에 대부분의 설정 옵션을 적용할 수 있기 때문이라고 생각합니다.

2. 팁: 스케줄

두 번째 기교는 스케줄에 관한 것이다.기존 scheduling preset 또는 예상 동작by hand을 사용할 수 있습니다.
나는 개인적으로 기존의 사전 설정을 더욱 좋아한다. 왜냐하면 그것들은 이미 나의 요구를 만족시켰기 때문이다.예로는 부표nonOfficeHours를 참조하십시오.

{
  "schedule": [
    "after 10pm every weekday",
    "before 5am every weekday",
    "every weekend"
  ]
}

보통 우리는 이 기간 동안 일하지 않는다.이것은 우리가 CI 시스템을 필요로 할 때 Reformation으로 인한 구축이 우리의 CI 시스템에서 자원을 훔치지 않고 기능 개발에 전념할 수 있음을 확신할 수 있다는 것을 의미한다.
다른 정책은 서로 다른 의존 그룹을 위해 서로 다른 스케줄링 정책을 적용하는 것이다.아마도 당신은 매달 한 번devDependencies만 업데이트하면 충분할 것입니다. 가능한 한 빨리 production dependencies의 최신 정보를 업데이트하고 싶습니다.

3. 팁: 자동 결합

가장 좋은 의존항 업데이트는 무엇입니까?네가 전혀 눈치채지 못했던 것들, 그렇지?Automerging 이 기능을 통해 이러한 이점을 누릴 수 있습니다.automergeType=branch를 설정하면 이를 실현할 수 있습니다.
Renove는 먼저 업데이트를 사용하여 새 브랜치를 열고 CI 시스템이 모든 파이프라인을 통해 검사할 때까지 기다립니다.만일 모든 것이 정상적이고 모든 테스트가 통과되면 분기는 PR을 만들지 않고 직접 통합됩니다. 파이프가 실패한 경우에만 Refrove는 PR을 만들어서 업데이트와 상태를 알려 줍니다.
일반적으로, 모든 의존항과 업데이트 유형에 이 옵션을 사용하는 것을 권장하지 않습니다.그러나 일부 비관건적인 문제에 대해서는 매우 유용할 수 있다.또한 CI 파이프라인에 의존할 수 있는지 확인해야 합니다.

4. 팁: PRs 수량 제한

또 다른 유용한 팁은 PRs의 수를 제한하는 것이다.Renove는 두 가지 유형의 제한을 알고 있습니다.
첫 번째 제한은 by hour입니다."prHourlyLimit": 3를 사용하여 구성할 수 있습니다.
두 번째 제한은 총계를 가리키며, 이렇게 하면 설정의 동시 PRs 수량을 영원히 받지 못할 것이다."prConcurrentLimit": 5를 사용하여 구성 가능
이 설정은 또한 귀하의 CI 시스템을 위해 가치 있는 자원을 절약할 수 있습니다.또한 Dashboard 기능과 함께 사용하면 오픈 PRs에 대한 개요를 잃어버리지 않을 수 있습니다.반면 Refrove는 저장소에서 GitHub Issue 를 열 것입니다. 업데이트에 대한 설명을 얻을 수 있습니다. 이 업데이트는 현재 요금의 제한을 받고 있습니다.
이 밖에 다른 이름priority의 설정과 결합할 수 있습니다.여기서 기본적으로 의존항(그룹)을 설정할 수 있습니다priority index.숫자가 클수록 업데이트를 적용하는 시간이 빨라진다.

5. 팁: 종속성 및 업데이트 유형 제외

마지막 힌트도 뻔한 것 같은데 제가 설명해 드릴게요.exluding entire dependencies부터 시작합시다.물론 전체 의존항을 간단하게 비활성화할 수 있지만, 내가 진정으로 원하는 것은 저장소 하위 디렉터리의 의존항입니다.특히 Monorepository에서 일하면 Lerna나 Nx를 사용할 수도 있고 여러 개의 파일이 있을 수도 있습니다.
이런 의존성을 감안하면 우리도 늘 리모델링을 원하지 않는다.
따라서 ignorePath 구성을 사용할 수 있습니다.

{
  "ignorePaths": ["**/examples/**"]
}

다른 피할 수 있는 PRs는 수동으로 업데이트하는 것이 가장 좋은 PRs입니다. 예를 들어 package.json 사용자가 사용하는 프레임워크에 대한 업데이트입니다. major많은 상황에서 프레임워크 작성자는 각도와 Nx 구역 등 breaking changes 또는 code mods를 제공했다.또한 updaters 업데이트라도 typescript는 수동 절차가 필요할 때가 있습니다.
matchUpdateType 구성을 사용하여 원하는 정책을 설정할 수 있습니다.

{
  "packageRules": [
    {
      "matchUpdateTypes": ["major"],
      "labels": ["UPDATE-MAJOR"]
    }
  ]
}

5+1 프롬프트: 리모델링 사용 안 함

마지막으로 가장 중요하지 않은 것은 리메이크 기능이 완전히 비활성화되었음을 고려해야 한다는 것이다.비록 이것은 자동화 해결 방안이지만, 당신의 시간을 절약할 수 있을 것입니다. 그러나, 그것은 여전히 당신의 시간을 필요로 합니다.
나에게 있어서 메모리 라이브러리에서 의존적인 로봇을 사용해야만 의미가 있다. 왜냐하면 그것은 매우 오랫동안 존재했기 때문이다. 그리고 너는 정말 프로젝트에서 계속 일하고 싶기 때문이다.만약 그렇지 않다면, 아마도 보조 항목이나 학습 항목에서, 나는 그것을 사용하는 것을 권장하지 않을 것이다.이러한 상황에서 중점은 달라야 한다. 프로젝트의 최신 업데이트가 필요하지 않을 수도 있다. 만약 당신이 몇 주나 몇 달 후에 돌아와서 계속한다면, 수천 수만의 공개 PRs에 시달리고 싶지 않을 것이다.

추가 팁: 구성 유효성 검사 프로그램 업데이트

들어봤어schematics?
현재 설정을 변경하려면 주 지점에 통합하기 전에 설정을 검증하는 것이 좋습니다.
따라서 renovate-config-validator:

# Install renovate globally
npm install renovate -g

# Execute this command in the root of your repo
npx renovate-config-validator

이게 다 내 쪽이야.너는 다른 유용한 건의나 전략을 알고 있니?만약 그렇다면 아래의 평론에 써 주십시오.
해피 코딩: -)