오늘날 대부분의 소프트웨어 제품은 팀으로 개발됩니다. 성공적인 팀 개발의 조건은 간단한 다이어그램 형태로 표현될 수 있습니다.

코드를 작성한 후에는 다음 사항을 확인해야 합니다.

1. Работает.
2. 동료가 작성한 코드를 포함하여 어떤 것도 깨지지 않습니다.

두 가지 조건이 모두 충족되면 성공의 길로 들어서게 됩니다. 이러한 조건을 쉽게 확인하고 수익성 있는 경로에서 벗어나지 않기 위해 우리는 지속적 통합(Continuous Integration)을 생각해냈습니다.

CI는 코드를 가능한 한 자주 전체 제품 코드에 통합하는 워크플로우입니다. 그리고 단순히 통합하는 것이 아니라 모든 것이 제대로 작동하는지 지속적으로 확인합니다. 많이, 자주 확인해야 하기 때문에 자동화에 대해 생각해 볼 가치가 있습니다. 모든 것을 수동으로 확인할 수 있지만 그렇게 해서는 안 됩니다. 그 이유는 다음과 같습니다.

• 친애하는 사람들. 프로그래머의 한 시간 작업은 서버의 한 시간 작업보다 비쌉니다.
• 사람들은 실수를 한다. 따라서 잘못된 브랜치에서 테스트가 실행되거나 테스터를 위해 잘못된 커밋이 컴파일되는 상황이 발생할 수 있습니다.
• 사람들은 게으르다. 가끔 작업을 마치면 "확인할 것이 무엇입니까? "라는 생각이 듭니다. 나는 두 줄을 썼습니다 - 모든 것이 작동합니다! 여러분 중에도 가끔 그런 생각을 하시는 분들이 계시리라 생각합니다. 하지만 항상 확인해야 합니다.

Nikolai Nesterov는 Avito 모바일 개발 팀에서 지속적인 통합이 어떻게 구현 및 개발되었는지, 어떻게 하루에 0에서 450개의 빌드로 이동했는지, 그리고 빌드 기계가 하루 200시간 동안 조립되었는지에 대해 말합니다.네스테로프)는 CI/CD Android 애플리케이션의 모든 진화적 변화에 참여하고 있습니다.

이 이야기는 Android 명령의 예를 기반으로 하지만 대부분의 접근 방식은 iOS에도 적용 가능합니다.

옛날 옛적에 한 사람이 Avito Android 팀에서 일했습니다. 정의에 따르면 그는 지속적인 통합에서 아무것도 필요하지 않았습니다. 통합할 사람이 없었습니다.

그러나 애플리케이션이 성장하고 점점 더 많은 새로운 작업이 등장했으며 그에 따라 팀도 성장했습니다. 어느 시점에서는 코드 통합 프로세스를 보다 공식적으로 확립해야 할 때입니다. Git flow를 사용하기로 결정했습니다.

Git 흐름의 개념은 잘 알려져 있습니다. 프로젝트에는 하나의 공통 개발 분기가 있으며, 각각의 새로운 기능에 대해 개발자는 별도의 분기를 잘라서 커밋하고 푸시한 다음 코드를 개발 분기에 병합하려는 경우 풀 요청. 지식을 공유하고 접근 방식에 대해 논의하기 위해 코드 검토를 도입했습니다. 즉, 동료가 서로의 코드를 확인하고 확인해야 합니다.

수표

눈으로 코드를 보는 것은 멋지지만 충분하지 않습니다. 따라서 자동 검사가 도입되었습니다.

• 우선, 확인해보겠습니다 방주 조립.
• 많은 Junit 테스트.
• 우리는 코드 적용 범위를 고려합니다, 테스트를 실행 중이기 때문입니다.

이러한 검사를 실행하는 방법을 이해하기 위해 Avito의 개발 프로세스를 살펴보겠습니다.

다음과 같이 개략적으로 표현할 수 있습니다.

• 개발자가 노트북에 코드를 작성합니다. 커밋 후크를 사용하거나 단순히 백그라운드에서 검사를 실행하여 바로 여기에서 통합 검사를 실행할 수 있습니다.
• 개발자는 코드를 푸시한 후 풀 요청을 엽니다. 코드가 개발 브랜치에 포함되려면 코드 검토를 거쳐 필요한 수의 확인을 수집해야 합니다. 여기에서 확인 및 빌드를 활성화할 수 있습니다. 모든 빌드가 성공할 때까지 풀 요청을 병합할 수 없습니다.
• 끌어오기 요청이 병합되고 코드가 개발에 포함된 후에는 편리한 시간(예: 모든 서버가 비어 있는 밤)을 선택하고 원하는 만큼 검사를 실행할 수 있습니다.

노트북에서 스캔을 실행하는 것을 좋아하는 사람은 아무도 없었습니다. 개발자가 기능을 완료하면 신속하게 해당 기능을 푸시하고 끌어오기 요청을 열고 싶어합니다. 이 순간 몇 가지 긴 검사가 시작되면 이는 매우 즐겁지 않을 뿐만 아니라 개발 속도도 느려집니다. 노트북이 무언가를 검사하는 동안에는 정상적으로 작업할 수 없습니다.

우리는 밤에 검사를 실행하는 것을 정말 좋아했습니다. 시간과 서버가 많고 돌아다닐 수 있기 때문입니다. 그러나 불행하게도 기능 코드가 개발되면 개발자는 CI에서 발견한 오류를 수정하려는 동기가 훨씬 줄어듭니다. 아침 보고서에서 발견된 모든 오류를 살펴보면서 언젠가는 수정해야겠다는 생각이 주기적으로 들었습니다. 이제 Jira에 제가 시작하고 싶은 멋진 새 작업이 있기 때문입니다.

검사가 풀 요청을 차단하면 동기가 충분한 것입니다. 빌드가 녹색으로 바뀔 때까지 코드가 개발되지 않아 작업이 완료되지 않기 때문입니다.

결과적으로 우리는 다음 전략을 선택했습니다. 밤에 최대한 많은 검사 세트를 실행하고 그 중 가장 중요한 검사와 가장 중요하게는 끌어오기 요청에서 가장 빠른 검사를 시작합니다. 하지만 우리는 거기서 멈추지 않고 동시에 야간 모드에서 풀 요청 확인으로 전환할 수 있도록 확인 속도를 최적화합니다.

당시에는 모든 빌드가 매우 빠르게 완료되었으므로 ARK 빌드, Junit 테스트 및 코드 적용 범위 계산을 끌어오기 요청에 대한 차단 장치로 포함시켰습니다. 우리는 그것을 켜고, 생각해보고, 필요하지 않다고 생각하여 코드 적용을 포기했습니다.

기본 CI를 완전히 구축하는 데 이틀이 걸렸습니다. (이하 예상 시간은 대략적인 것이며 규모에 따라 필요합니다.)

그 후 우리는 더 깊이 생각하기 시작했습니다. 우리가 올바르게 확인하고 있습니까? 끌어오기 요청에 따라 빌드를 올바르게 실행하고 있나요?

풀 요청이 열린 브랜치의 마지막 커밋에서 빌드를 시작했습니다. 그러나 이 커밋 테스트는 개발자가 작성한 코드가 작동한다는 것만 보여줄 수 있습니다. 그러나 그들은 그가 아무것도 부수지 않았다는 것을 증명하지 않습니다. 실제로 기능이 병합된 후 개발 브랜치의 상태를 확인해야 합니다.

이를 위해 우리는 간단한 bash 스크립트를 작성했습니다. premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

여기에서는 개발의 모든 최신 변경 사항을 간단히 가져와서 현재 분기에 병합합니다. 우리는 모든 빌드의 첫 번째 단계로 premerge.sh 스크립트를 추가하고 우리가 원하는 것이 무엇인지 정확하게 확인하기 시작했습니다. 완성.

문제를 현지화하고, 해결책을 찾고, 이 스크립트를 작성하는 데 XNUMX일이 걸렸습니다.

애플리케이션이 개발되고 점점 더 많은 작업이 나타나고 팀이 성장했으며 premerge.sh가 때때로 우리를 실망시키기 시작했습니다. 개발에 충돌하는 변경 사항이 있어 빌드가 중단되었습니다.

이것이 어떻게 일어나는지에 대한 예:

두 명의 개발자가 동시에 기능 A와 B에 대한 작업을 시작합니다. 기능 A의 개발자는 프로젝트에서 사용되지 않는 기능을 발견합니다. answer() 그리고 훌륭한 보이스카우트처럼 그것을 제거합니다. 동시에 기능 B의 개발자는 자신의 분기에서 이 함수에 대한 새로운 호출을 추가합니다.

개발자는 작업을 완료하는 동시에 끌어오기 요청을 엽니다. 빌드가 시작되고 premerge.sh는 최신 개발 상태와 관련된 두 풀 요청을 모두 확인합니다. 모든 확인은 녹색입니다. 그 후, 기능 A의 풀 요청이 병합되고, 기능 B의 풀 요청이 병합됩니다... 붐! 개발 코드에 존재하지 않는 함수에 대한 호출이 포함되어 있으므로 개발 중단이 발생합니다.

발전하지 않을 때, 지역 재해. 팀 전체가 아무것도 수집하여 테스트를 위해 제출할 수 없습니다.

분석, 네트워크, 데이터베이스 등 인프라 작업을 가장 자주 수행하게 되었습니다. 즉, 다른 개발자가 사용하는 함수와 클래스를 작성한 사람은 바로 나였습니다. 그렇기 때문에 나는 비슷한 상황에 자주 직면하게 되었다. 한동안 이 사진을 걸어두기도 했는데요.

이것이 우리에게 적합하지 않았기 때문에 우리는 이를 방지하는 방법에 대한 옵션을 탐색하기 시작했습니다.

개발을 중단하지 않는 방법

첫 번째 옵션 : 개발을 업데이트할 때 모든 풀 리퀘스트를 다시 빌드하세요. 이 예에서 기능 A가 포함된 풀 요청이 개발에 처음 포함되는 경우 기능 B의 풀 요청이 다시 빌드되고 그에 따라 컴파일 오류로 인해 검사가 실패합니다.

이 작업에 소요되는 시간을 이해하려면 두 개의 PR이 있는 예를 고려해 보세요. 두 번의 PR(두 번의 빌드, 두 번의 검사 실행)을 엽니다. 첫 번째 PR이 개발로 병합된 후 두 번째 PR을 다시 빌드해야 합니다. 전체적으로 2개의 PR에는 1번의 확인 실행(3 + XNUMX = XNUMX)이 필요합니다.

원칙적으로는 괜찮습니다. 그런데 통계를 보니 저희 팀의 일반적인 상황은 공개 PR이 10개였고, 확인 횟수는 진행 상황의 합이 10 + 9 +... + 1 = 55였습니다. 즉, 10개를 수락하는 것입니다. PR은 55번 재구축해야 합니다. 그리고 이것은 모든 검사가 처음으로 통과하고 수십 개가 처리되는 동안 아무도 추가 끌어오기 요청을 열지 않는 이상적인 상황입니다.

자신이 "병합" 버튼을 가장 먼저 클릭해야 하는 개발자라고 상상해 보세요. 이웃이 이 작업을 수행하면 모든 빌드가 다시 완료될 때까지 기다려야 하기 때문입니다... 아니요, 작동하지 않습니다. , 개발 속도가 심각하게 느려질 것입니다.

두 번째 가능한 방법: 코드 검토 후 풀 요청을 수집합니다. 즉, 끌어오기 요청을 열고 동료로부터 필요한 승인 수를 수집하고 필요한 사항을 수정한 다음 빌드를 시작합니다. 성공하면 풀 요청이 개발에 병합됩니다. 이 경우 추가 재시작은 없지만 피드백 속도가 크게 느려집니다. 개발자로서 저는 끌어오기 요청을 열면 즉시 그것이 작동하는지 확인하고 싶습니다. 예를 들어, 테스트가 실패하면 신속하게 수정해야 합니다. 빌드가 지연되는 경우 피드백이 느려지고 전체 개발이 느려집니다. 이것은 우리에게도 적합하지 않았습니다.

결과적으로 세 번째 옵션만 남았습니다. 자전거. 우리의 모든 코드와 소스는 Bitbucket 서버의 저장소에 저장됩니다. 따라서 우리는 Bitbucket용 플러그인을 개발해야 했습니다.

이 플러그인은 풀 요청 병합 메커니즘을 재정의합니다. 시작은 표준입니다. PR이 열리고 모든 어셈블리가 시작되고 코드 검토가 완료됩니다. 그러나 코드 검토가 완료되고 개발자가 "병합"을 클릭하기로 결정한 후 플러그인은 검사가 실행된 개발 상태를 확인합니다. 빌드 후에 개발이 업데이트된 경우 플러그인은 이러한 풀 요청이 메인 브랜치에 병합되는 것을 허용하지 않습니다. 비교적 최근에 개발된 빌드를 다시 시작하기만 하면 됩니다.

변경 사항이 충돌하는 예에서는 컴파일 오류로 인해 이러한 빌드가 실패합니다. 따라서 기능 B의 개발자는 코드를 수정하고 검사를 다시 시작해야 하며 그러면 플러그인이 자동으로 끌어오기 요청을 적용합니다.

이 플러그인을 구현하기 전에는 끌어오기 요청당 평균 2,7회의 검토가 실행되었습니다. 플러그인을 사용하면 3,6개의 출시가 있었습니다. 이것은 우리에게 적합했습니다.

이 플러그인에는 단점이 있다는 점은 주목할 가치가 있습니다. 빌드를 한 번만 다시 시작한다는 것입니다. 즉, 상충되는 변화가 전개될 수 있는 작은 창이 여전히 존재합니다. 그러나 그럴 가능성은 낮으며, 우리는 시작 횟수와 실패 가능성을 절충했습니다. XNUMX년 동안 딱 한 번만 발사됐으니 아마도 헛된 일은 아니었을 것입니다.

Bitbucket 플러그인의 첫 번째 버전을 작성하는 데 XNUMX주가 걸렸습니다.

새로운 수표

그러는 동안 우리 팀은 계속해서 성장했습니다. 새로운 검사가 추가되었습니다.

우리는 실수를 예방할 수 있다면 왜 실수를 저지르는가?라고 생각했습니다. 그리고 그것이 바로 그들이 구현한 이유입니다. 정적 코드 분석. 우리는 Android SDK에 포함된 Lint부터 시작했습니다. 하지만 당시 그는 Kotlin 코드로 작업하는 방법을 전혀 몰랐고 이미 애플리케이션의 75%가 Kotlin으로 작성되어 있었습니다. 그래서 내장된 것들이 Lint에 추가되었습니다. Android 스튜디오를 확인합니다.

이를 위해 우리는 많은 변형 작업을 수행해야 했습니다. Android Studio를 가져와 Docker에 패키징하고 가상 모니터가 있는 CI에서 실행하여 실제 노트북에서 실행되는 것처럼 생각하도록 했습니다. 그러나 그것은 효과가 있었습니다.

우리가 글을 많이 쓰기 시작한 것도 이 시기였습니다. 계측 테스트 그리고 구현 스크린샷 테스트. 별도의 작은 뷰에 대한 참조 스크린샷을 생성하는 경우이며, 테스트는 해당 뷰에서 스크린샷을 찍어 표준과 픽셀 단위로 직접 비교하는 것으로 구성됩니다. 불일치가 있는 경우 레이아웃이 어딘가 잘못되었거나 스타일에 문제가 있음을 의미합니다.

그러나 계측 테스트와 스크린샷 테스트는 에뮬레이터 또는 실제 장치와 같은 장치에서 실행되어야 합니다. 테스트가 많고 자주 실행된다는 점을 고려하면 팜 전체가 필요합니다. 자신의 농장을 시작하는 것은 너무 노동 집약적이므로 기성 옵션인 Firebase Test Lab을 찾았습니다.

Firebase 테스트 랩

Firebase는 Google 제품이기 때문에 선택되었습니다. 즉, 신뢰할 수 있고 결코 죽지 않아야 함을 의미합니다. 가격은 합리적입니다. 실제 장치를 작동하면 시간당 5달러, 에뮬레이터를 작동하면 시간당 1$입니다.

CI에 Firebase Test Lab을 구현하는 데 약 XNUMX주가 걸렸습니다.

하지만 팀은 계속해서 성장했고, 불행하게도 Firebase는 우리를 실망시키기 시작했습니다. 그 당시에는 SLA가 없었습니다. 때때로 Firebase는 필요한 수의 장치가 테스트에 사용 가능해질 때까지 기다리게 하고 우리가 원하는 대로 즉시 실행을 시작하지 않았습니다. 줄을 서서 기다리는 데는 최대 XNUMX분이 걸렸는데, 이는 매우 긴 시간입니다. 모든 PR에 대해 계측 테스트가 실행되었고, 지연으로 인해 개발 속도가 정말 느려졌으며, 월별 청구서에는 총계가 포함되었습니다. 일반적으로 팀이 충분히 성장했기 때문에 Firebase를 포기하고 사내에서 일하기로 결정했습니다.

도커 + 파이썬 + 배쉬

우리는 Docker를 가져와 그 안에 에뮬레이터를 추가하고 Python으로 간단한 프로그램을 작성했습니다. 이 프로그램은 적절한 순간에 필요한 버전에 필요한 수의 에뮬레이터를 가져오고 필요할 때 중지합니다. 그리고 물론 두 개의 bash 스크립트도 있습니다. 그것들이 없다면 우리는 어디에 있을까요?

자체 테스트 환경을 만드는 데 XNUMX주가 걸렸습니다.

결과적으로 모든 끌어오기 요청에 대해 광범위한 병합 차단 검사 목록이 있었습니다.

• ARK 조립;
• Junit 테스트;
• 린트;
• Android 스튜디오 확인;
• 계측 테스트
• 스크린샷 테스트.

이로 인해 발생할 수 있는 많은 고장을 방지할 수 있었습니다. 기술적으로는 모든 것이 작동했지만 개발자들은 결과를 기다리는 시간이 너무 길다고 불평했습니다.

얼마나 긴가요? 우리는 Bitbucket과 TeamCity의 데이터를 분석 시스템에 업로드하고 다음과 같은 사실을 깨달았습니다. 평균 대기 시간 45분. 즉, 개발자가 풀 리퀘스트를 열 때 빌드 결과가 나올 때까지 평균 45분을 기다립니다. 제 생각에는 이것이 많은데 그렇게 일할 수는 없습니다.

물론 우리는 모든 빌드 속도를 높이기로 결정했습니다.

속도를 높이자

빌드가 종종 대기열에 있는 것을 보고 우리가 가장 먼저 하는 일은 하드웨어를 더 구입했습니다 — 광범위한 개발이 가장 간단합니다. 빌드 대기열이 중지되었지만 일부 검사 자체가 매우 오랜 시간이 걸렸기 때문에 대기 시간이 약간만 줄었습니다.

시간이 너무 오래 걸리는 수표 제거

우리의 지속적인 통합은 이러한 유형의 오류와 문제를 포착할 수 있습니다.

• 안 할거야. CI는 변경 사항 충돌로 인해 무언가가 빌드되지 않을 때 컴파일 오류를 포착할 수 있습니다. 이미 말했듯이 아무도 아무것도 조립할 수 없고 개발이 중단되며 모두가 긴장하게 됩니다.
• 행동의 버그. 예를 들어 애플리케이션이 빌드되었지만 버튼을 누르면 충돌이 발생하거나 버튼이 전혀 누르지 않는 경우가 있습니다. 이러한 버그가 사용자에게 영향을 미칠 수 있으므로 이는 좋지 않습니다.
• 레이아웃의 버그. 예를 들어, 버튼을 클릭했지만 왼쪽으로 10픽셀 이동했습니다.
• 기술부채 증가.

이 목록을 살펴본 후 우리는 처음 두 가지 사항만이 중요하다는 것을 깨달았습니다. 우리는 그러한 문제를 먼저 파악하고 싶습니다. 레이아웃의 버그는 디자인 검토 단계에서 발견되며 이후 쉽게 수정할 수 있습니다. 기술 부채를 처리하려면 별도의 프로세스와 계획이 필요하므로 풀 리퀘스트에서는 테스트하지 않기로 결정했습니다.

이 분류를 바탕으로 전체 점검 목록을 개편했습니다. 지워진 린트 프로젝트에 얼마나 많은 문제가 있었는지에 대한 보고서를 생성하기 위해 출시를 하룻밤 사이에 연기했습니다. 기술부채와는 별도로 작업하기로 합의했고, Android Studio 검사가 완전히 중단되었습니다.. 검사를 실행하기 위한 Docker의 Android Studio는 흥미롭게 들리지만 지원에 많은 문제를 일으킵니다. Android Studio 버전을 업데이트하면 이해할 수 없는 버그로 인해 어려움을 겪게 됩니다. 라이브러리가 그다지 안정적이지 않고 오탐(false positive)이 발생하여 스크린샷 테스트를 지원하는 것도 어려웠습니다. 스크린샷 테스트가 체크리스트에서 제거되었습니다..

결과적으로 우리는 다음과 같은 결과를 얻었습니다.

• ARK 조립;
• Junit 테스트;
• 계측 테스트.

Gradle 원격 캐시

무거운 점검 없이 모든 것이 좋아졌습니다. 하지만 완벽함에는 한계가 없습니다!

우리 애플리케이션은 이미 약 150개의 Gradle 모듈로 분할되었습니다. Gradle 원격 캐시는 일반적으로 이 경우에 잘 작동하므로 우리는 이를 시도해 보기로 결정했습니다.

Gradle 원격 캐시는 개별 모듈의 개별 작업에 대한 빌드 아티팩트를 캐시할 수 있는 서비스입니다. Gradle은 실제로 코드를 컴파일하는 대신 HTTP를 사용하여 원격 캐시를 두드리고 누군가가 이미 이 작업을 수행했는지 묻습니다. 그렇다면 단순히 결과를 다운로드합니다.

Gradle은 Docker 이미지를 제공하므로 Gradle 원격 캐시를 실행하는 것은 쉽습니다. 우리는 이 일을 XNUMX시간 만에 해냈습니다.

당신이 해야 할 일은 Docker를 실행하고 프로젝트에 한 줄을 작성하는 것뿐이었습니다. 하지만 빠르게 시작할 수는 있지만 모든 것이 제대로 작동하려면 꽤 많은 시간이 걸릴 것입니다.

아래는 캐시 미스 그래프입니다.

처음에는 캐시 누락 비율이 약 65였습니다. 20주 후에는 이 값을 XNUMX%로 늘릴 수 있었습니다. Android 애플리케이션이 수집하는 작업에는 Gradle이 캐시를 놓친 이상한 전이적 종속성이 있는 것으로 나타났습니다.

캐시를 연결함으로써 빌드 속도가 크게 향상되었습니다. 하지만 조립 외에도 계측 테스트도 있는데 시간이 오래 걸립니다. 모든 풀 요청에 대해 모든 테스트를 실행할 필요는 없을 수도 있습니다. 이를 알아보기 위해 영향 분석을 사용합니다.

영향 분석

풀 요청 시 git diff를 수집하고 수정된 Gradle 모듈을 찾습니다.

변경된 모듈과 이에 종속된 모든 모듈을 확인하는 계측 테스트만 실행하는 것이 합리적입니다. 인접한 모듈에 대해 테스트를 실행하는 것은 의미가 없습니다. 코드가 변경되지 않았으며 아무 것도 깨질 수 없습니다.

계측 테스트는 최상위 애플리케이션 모듈에 위치해야 하기 때문에 그렇게 간단하지 않습니다. 우리는 각 테스트가 어떤 모듈에 속하는지 이해하기 위해 바이트코드 분석과 함께 경험적 방법을 사용했습니다.

관련 모듈만 테스트하도록 계측 테스트 작업을 업그레이드하는 데 약 XNUMX주가 걸렸습니다.

검사 속도를 높이는 조치가 성공적으로 이루어졌습니다. 45분에서 약 15분으로 늘어났습니다. 빌드를 위해 XNUMX분을 기다리는 것은 이미 정상입니다.

그러나 이제 개발자들은 어떤 빌드가 시작되고 있는지, 로그를 볼 수 있는 위치, 빌드가 빨간색인 이유, 어떤 테스트가 실패했는지 등을 이해하지 못한다고 불평하기 시작했습니다.

피드백 문제로 인해 개발 속도가 느려지므로 각 PR 및 빌드에 대해 최대한 명확하고 자세한 정보를 제공하려고 노력했습니다. 우리는 PR에 대한 Bitbucket의 댓글로 시작하여 어떤 빌드가 실패했는지, 그 이유를 표시하고 Slack에 대상 메시지를 작성했습니다. 결국 우리는 현재 실행 중인 모든 빌드 목록과 해당 상태(대기 중, 실행 중, 충돌 또는 완료)가 포함된 페이지용 PR 대시보드를 만들었습니다. 빌드를 클릭하고 해당 로그를 확인할 수 있습니다.

자세한 피드백을 받는 데 XNUMX주가 소요되었습니다.

계획

최근 역사로 넘어가 보겠습니다. 피드백 문제를 해결한 후 우리는 새로운 수준에 도달했습니다. 자체 에뮬레이터 팜을 구축하기로 결정했습니다. 테스트와 에뮬레이터가 많으면 관리하기가 어렵습니다. 결과적으로 모든 에뮬레이터는 유연한 리소스 관리를 통해 k8s 클러스터로 이동되었습니다.

그 외에도 다른 계획이 있습니다.

• 보풀 반환 (및 기타 정적 분석). 우리는 이미 이 방향으로 노력하고 있습니다.
• PR 차단기에서 모든 것을 실행하십시오. 엔드투엔드 테스트 모든 SDK 버전에서.

그래서 우리는 Avito의 지속적인 통합 개발 역사를 추적했습니다. 이제 저는 경험이 풍부한 관점에서 몇 가지 조언을 드리고 싶습니다.

Советы

딱 한 가지 조언을 하자면 이렇습니다.

쉘 스크립트에 주의하세요!

Bash는 매우 유연하고 강력한 도구이며 스크립트 작성이 매우 편리하고 빠릅니다. 하지만 당신은 그것으로 인해 함정에 빠질 수 있고, 불행하게도 우리도 그 함정에 빠졌습니다.

모든 것은 빌드 머신에서 실행되는 간단한 스크립트로 시작되었습니다.

#!/usr/bin/env bash
./gradlew assembleDebug

그러나 아시다시피 시간이 지남에 따라 모든 것이 발전하고 더 복잡해집니다. 하나의 스크립트를 다른 스크립트에서 실행하고 거기에 몇 가지 매개 변수를 전달합시다. 결국 우리는 현재 어느 수준의 bash 중첩인지 결정하는 함수를 작성해야 했습니다. 필요한 따옴표를 삽입하여 모든 것을 시작하십시오.

그러한 스크립트를 개발하는 데 드는 인건비를 상상할 수 있습니다. 이 함정에 빠지지 말라고 조언합니다.

무엇을 교체할 수 있습니까?

• 모든 스크립팅 언어. 에 쓰기 Python 또는 Kotlin 스크립트 스크립트가 아닌 프로그래밍이기 때문에 더 편리합니다.
• 또는 모든 빌드 로직을 다음 형식으로 설명합니다. 사용자 정의 Gradle 작업 당신의 프로젝트를 위해.

우리는 두 번째 옵션을 선택하기로 결정했고 이제 모든 bash 스크립트를 체계적으로 삭제하고 많은 사용자 정의 Gradle 작업을 작성하고 있습니다.

팁 #2: 인프라를 코드에 저장하세요.

Continuous Integration 설정을 Jenkins나 TeamCity 등의 UI 인터페이스가 아닌 프로젝트 저장소에 직접 텍스트 파일 형식으로 저장하면 편리합니다. 이는 버전 가능성을 제공합니다. 다른 브랜치에서 코드를 롤백하거나 빌드하는 것은 어렵지 않습니다.

스크립트는 프로젝트에 저장할 수 있습니다. 환경을 어떻게 해야 할까요?

팁 #3: Docker는 환경에 도움이 될 수 있습니다.

확실히 Android 개발자에게 도움이 될 것입니다. 안타깝게도 iOS에는 아직 그런 기능이 없습니다.

다음은 jdk 및 android-sdk가 포함된 간단한 docker 파일의 예입니다.

FROM openjdk:8

ENV SDK_URL="https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip" 
    ANDROID_HOME="/usr/local/android-sdk" 
    ANDROID_VERSION=26 
    ANDROID_BUILD_TOOLS_VERSION=26.0.2

# Download Android SDK
RUN mkdir "$ANDROID_HOME" .android 
    && cd "$ANDROID_HOME" 
    && curl -o sdk.zip $SDK_URL 
    && unzip sdk.zip 
    && rm sdk.zip 
    && yes | $ANDROID_HOME/tools/bin/sdkmanager --licenses

# Install Android Build Tool and Libraries
RUN $ANDROID_HOME/tools/bin/sdkmanager --update
RUN $ANDROID_HOME/tools/bin/sdkmanager "build-tools;${ANDROID_BUILD_TOOLS_VERSION}" 
    "platforms;android-${ANDROID_VERSION}" 
    "platform-tools"

RUN mkdir /application
WORKDIR /application

이 Docker 파일을 작성하고(비밀을 말하겠습니다. 작성할 필요는 없지만 GitHub에서 미리 만들어진 파일을 가져오면 됩니다) 이미지를 조립하면 애플리케이션을 구축할 수 있는 가상 머신이 생성됩니다. Junit 테스트를 실행합니다.

이것이 타당한 두 가지 주요 이유는 확장성과 반복성입니다. Docker를 사용하면 이전 빌드와 정확히 동일한 환경을 갖게 될 XNUMX개의 빌드 에이전트를 빠르게 생성할 수 있습니다. 이는 CI 엔지니어의 삶을 훨씬 쉽게 만듭니다. android-sdk를 docker에 푸시하는 것은 매우 쉽지만 에뮬레이터를 사용하면 조금 더 어렵습니다. 조금 더 열심히 작업해야 합니다(또는 GitHub에서 완성된 것을 다시 다운로드해야 합니다).

팁 4: 검사는 검사를 위해서가 아니라 사람을 위해 수행된다는 점을 잊지 마십시오.

개발자에게는 빠르고 가장 중요한 피드백이 매우 중요합니다. 무엇이 문제인지, 어떤 테스트가 실패했는지, 빌드 로그는 어디서 볼 수 있나요?

팁 #5: 지속적 통합을 개발할 때는 실용적이게 하세요.

방지하려는 오류 유형이 무엇인지, 얼마나 많은 리소스, 시간, 컴퓨터 시간을 소비할 의향이 있는지 명확하게 이해하십시오. 예를 들어 너무 오래 걸리는 점검은 밤새 연기될 수 있습니다. 그리고 그다지 중요하지 않은 오류를 포착한 오류는 완전히 버려야 합니다.

팁 #6: 미리 만들어진 도구를 사용하세요.

현재 클라우드 CI를 제공하는 회사는 많습니다.

이는 소규모 팀에 적합한 솔루션입니다. 아무것도 지원할 필요가 없으며 약간의 비용만 지불하고 애플리케이션을 구축하고 계측 테스트를 실행하기만 하면 됩니다.

팁 #7: 대규모 팀에서는 내부 솔루션이 더 수익성이 높습니다.

그러나 조만간 팀이 성장함에 따라 사내 솔루션의 수익성이 더욱 높아질 것입니다. 이러한 결정에는 한 가지 문제가 있습니다. 경제학에는 수익 감소의 법칙이 있습니다. 어떤 프로젝트에서든 후속 개선이 점점 더 어려워지고 점점 더 많은 투자가 필요합니다.

경제학은 지속적인 통합을 포함한 우리 삶 전체를 설명합니다. 저는 지속적인 통합의 각 개발 단계에 대한 인건비 일정을 작성했습니다.

개선이 점점 더 어려워지고 있음이 분명합니다. 이 그래프를 보면 팀 규모의 성장에 따라 지속적인 통합이 개발되어야 함을 알 수 있습니다. 두 사람으로 구성된 팀의 경우 내부 에뮬레이터 팜을 개발하는 데 50일을 소비하는 것은 평범한 아이디어입니다. 그러나 동시에 대규모 팀의 경우 지속적인 통합을 전혀 수행하지 않는 것도 통합 문제, 커뮤니케이션 문제 등으로 인해 나쁜 생각입니다. 시간이 더 걸릴 것입니다.

우리는 사람이 비싸고, 실수를 하고, 게으르기 때문에 자동화가 필요하다는 생각에서 시작했습니다. 하지만 사람들은 자동화도 합니다. 따라서 자동화에도 동일한 문제가 모두 적용됩니다.

• 자동화는 비용이 많이 듭니다. 노동 일정을 기억하십시오.
• 자동화에 있어서 사람들은 실수를 합니다.
• 모든 것이 그런 식으로 작동하기 때문에 때로는 자동화하는 것이 매우 게으른 경우도 있습니다. 왜 다른 것을 개선해야 하며, 이 모든 지속적인 통합이 필요한가요?

하지만 통계가 있습니다. 어셈블리의 20%에서 오류가 발견됩니다. 이는 개발자가 코드를 제대로 작성하지 않았기 때문이 아닙니다. 개발자들은 실수를 해도 개발에 이르지 않고 자동화된 검사를 통해 발견될 것이라고 확신하기 때문입니다. 따라서 개발자는 로컬에서 무언가를 실행하고 테스트하는 것보다 코드를 작성하고 흥미로운 것을 작성하는 데 더 많은 시간을 할애할 수 있습니다.

지속적인 통합을 실천하세요. 그러나 적당히.

그건 그렇고, Nikolai Nesterov는 훌륭한 보고서를 직접 제공할 뿐만 아니라 프로그램 위원회의 회원이기도 합니다. 앱컨퍼런스 다른 사람들이 당신을 위해 의미 있는 연설을 준비하도록 돕습니다. 다음 회의 프로그램의 완전성과 유용성은 다음 주제에 따라 평가될 수 있습니다. 일정. 자세한 내용은 22월 23~XNUMX일에 Infospace를 방문하세요.

출처 : habr.com