팀이나 앱 규모가 출시 프로세스에 영향을 미치나요? 글쎄요, 상황에 따라 다릅니다. 하나의 작은 팀으로 구성된 스타트업을 상상해 봅시다. 이 경우 팀에서는 일반적으로 기능을 만든 다음 출시합니다. 이제 많은 팀이 작업하는 뱅킹 앱과 같은 대규모 프로젝트를 상상해 보겠습니다. 이 경우 프로세스, 릴리스 주기 및 일부 관료주의가 있을 수 있습니다. 그렇지 않으면 혼란이 일어날 것입니다. 그렇다면 앱에 이러한 프로세스를 설정해야 한다는 것이 언제 명확해 집니까? 이 기사에서는 Dodo Pizza 앱(안드로이드 및 iOS)에 Release Train을 구현한 경험과 우리 팀이 Release Train을 구현하게 만든 문제에 대해 공유하겠습니다. 빠르게 성장하고 있는 Android 또는 iOS 프로젝트의 팀 리더/기술 리더이고 아직 출시 프로세스를 관리해 본 적이 없다면, 우리의 경험이 도움이 되기를 바랍니다. 예전에는 어땠나요? 2021년에 우리 팀에서는 이미 트렁크 기반 개발(TBD) 접근 방식을 사용하고 있었습니다. 기능 토글, 분해된 작업으로 코드를 다루고 단위 및 UI 테스트를 실행했습니다. 우리의 기능 분기는 오래 가지 못했고 CI가 작동했습니다. 릴리스 프로세스는 매우 간단했습니다. 기능을 출시할 준비가 된 사람이 누구든지 출시했습니다. 이상적인 시나리오 다음은 지점 작업 흐름의 대략적인 모습입니다. 여러 팀(회색, 파란색, 주황색, 녹색)이 다양한 기능을 개발했습니다. 우리는 TBD에 따라 작업했기 때문에 각 기능은 여러 개의 연속된 분기를 통해 존재할 수 있습니다. 예를 들어 회색 팀은 4단계로 기능을 만들고, 파란색과 주황색 팀은 1단계로, 녹색 팀은 2단계로 기능을 만들었습니다. 팀이 기능을 완료하면 릴리스를 출시할 수 있습니다. 예를 들어, 블루팀이 기능을 완료했다면 출시를 할 수 있습니다. 그런 다음 오렌지 팀은 기능을 완료하고 또 다른 릴리스를 수행합니다. 우리는 당시처럼 완벽한 흐름을 갖고 있었습니다. 어느 시점까지는 훌륭하게 작동했지만 모든 좋은 일에는 끝이 있습니다. 문제가 발생했습니다. 힘들고 혼잡하며 예측할 수 없습니다. 거대한 우리가 직면한 첫 번째 문제는 릴리스가 많은 기능을 축적하기 시작하고 너무 커졌다는 것입니다. 팀은 항상 기능을 즉시 출시하고 싶어하지 않았습니다. 릴리스 및 회귀 프로세스는 시간이 많이 걸리고 3~4일이 걸렸습니다. 따라서 기능이 작고 긴급하지 않은 경우에는 다른 팀에서 곧 릴리스를 수행하고 해당 릴리스에 포함될 것이기 때문에 항상 직접 릴리스할 수는 없습니다. 대략적으로 다음과 같았습니다. 이는 특히 팀 수가 증가하기 시작했을 때 매우 취약한 배열이었습니다. 많은 팀이 여러 가지 작은 기능을 개발했으며, 새 릴리스마다 새로운 코드의 총량이 엄청났습니다. 누군가 큰 기능을 출시하려면 전체를 함께 출시해야 했습니다. 매머드 거대한 릴리스의 결과는 다음과 같습니다. 지연된 회귀; 회귀 버그의 위험이 더 높습니다. 프로덕션에서 버그가 발생할 위험이 더 높습니다. 예시의 블루팀과 오렌지팀이 릴리즈를 원하지 않더라도 어떻게든 릴리즈가 이루어지도록 만들어야 했습니다. 병목 현상 모든 팀은 독특하고 모든 기능이 다릅니다. 때로는 여러 팀이 비슷한 시기에 작품을 마무리하는 상황이 발생하기도 했습니다. 이 경우에는 "기다려주세요. 내일 아침에 병합하겠습니다. 약속합니다!"라는 말이 많이 있었습니다. 돌아가다. 결국 이러한 병목 현상으로 인해 다음이 발생했습니다. 매머드로 변하는 방출; 지연된 릴리스는 특히 다른 모든 사람의 요구 사항이 충족되는 경우 릴리스 팀의 계획에 부정적인 영향을 미칩니다. 우리는 두 가지 중요한 변경이 필요했습니다. 릴리스 팀은 누군가를 기다릴 필요가 없습니다. 다른 모든 팀은 다음 릴리스가 언제 예상되는지 알아야 합니다. 예측 가능성 부족 블루 팀이 작은 기능을 만들고 오렌지 팀이 곧 출시할 것으로 기대한다고 상상해 보세요. 그러나 문제가 발생했고 오렌지 팀도 자체 문제로 인해 릴리스를 출시하지 못했습니다. 그 결과, 블루 팀은 해당 기능이 곧 생산될 것이라고 업계에 알렸지만 아직 충분하지 않은 것으로 나타났습니다. 따라서 해당 기능이 언제 출시될지 예측하는 것은 불가능합니다. 그렇다고 블루팀이 무책임하다는 뜻은 아닙니다. 매우 중요하거나 긴급한 기능이 있으면 당연히 직접 출시합니다. 그러나 다른 경우에는 사용자가 해당 기능을 언제 사용할 수 있는지 정확히 알 수 있는 방법이 없습니다. 짐작할 수 있듯이 우리는 이러한 문제를 꽤 자주 경험하고 있었습니다. 우리는 크기나 긴급성에 관계없이 고객이 생산 기능을 언제 얻을 수 있는지 정확히 알 수 있어야 했습니다. 3가지 문제(대규모 릴리스, 병목 현상, 예측 가능성 부족)는 모두 밀접하게 연관되어 있으며 서로를 보완합니다. 그러나 아마도 가장 기본적이고 중요한 것은 예측 가능성이 부족하다는 것입니다. 다른 문제가 발생합니다. 열차 출시 우리는 충분히 먹었습니다. 변화를 주어야 할 때였습니다. 우리가 그렇게 하는 데 도움이 되도록 되어 있었습니다. Release Train은 릴리스 트레인이라는 용어는 또는 릴리스 프로세스를 관리하는 다양한 의미를 갖습니다. 여기서는 예정된 출시 프로세스에 대해 이야기하겠습니다. 예정된 릴리스 프로세스 전담 팀 등 나는 " " 기사에서 Martin Fowler가 Release Train을 설명하는 방식과 제공한 정의(아마도 Martin의 것일 수도 있음)를 좋아합니다. 소스 코드 분기 관리 패턴 Thoughtworks가 기술 레이더에서 이것이 우리가 스스로 Release Train을 정의한 방법입니다. Release Train은 팀 간의 릴리스를 조정하는 프로세스입니다. 모든 릴리스는 기능 준비 여부에 관계없이 고정된 일정에 따라 이루어집니다. 기차는 누구도 기다려주지 않습니다. 늦으면 다음 시간을 기다려야 합니다. 색상으로 구분된 팀을 사용하여 몇 가지 예를 통해 분석해 보겠습니다. 매머드 문제 해결 Release Train은 일정에 따라 발생하며 누가 메인 브랜치에 무엇을 병합했는지에 의존하지 않습니다. 아래 예시에서는 블루팀과 오렌지팀의 기능이 공개됩니다. 나머지는 다음 열차를 기다립니다. 좀 더 기다리면 매머드를 얻을 수 있습니다. 병목 현상 해결 동시에 Release Train은 작업을 보다 효율적으로 계획하는 데 도움이 됩니다. 블루 팀이 원래 기능을 나중에 완료할 계획이었다고 가정해 보겠습니다. 하지만 모두가 출시일을 알고 있기 때문에 기능을 조기에 완료하기 위해 계획을 약간 재정비할 수 있습니다. 또는 반대로 다음 열차 시간에 절대 늦지 않을 것이라는 사실을 깨닫고 전체 일정을 알고 있기 때문에 안전하게 기능을 끝낼 수 있습니다. 아래 예에서 블루 팀은 릴리스에 도달하여 릴리스 전에 모든 변경 사항을 병합하기를 원했습니다. 그렇지 않으면 병목 현상이 발생할 수 있습니다. 가장 중요한 것은 Release Train이 입니다. 설계상 예측 가능성을 제공했다는 것 이러한 예는 어떤 사람들에게는 당연해 보일 수 있지만 문제가 발생하면 이를 해결했습니다. 릴리스에 문제가 없을 때는 Release Train을 사용하지 않았습니다. 문제가 쌓이면서 우리는 때가 왔다는 것을 깨달았습니다. 팀에서 릴리스 교육을 구현하는 방법 우리가 가장 먼저 한 일은 작성하는 것이었습니다. RFC는 프로젝트 작업을 시작하기 전에 사용하는 프로세스 자체와 설계 문서를 모두 나타냅니다. 일부는 특별히 RFC를 사용하고 일부는 ADR을 사용하며 일부는 보다 일반적인 용어인 Design Doc으로 부릅니다. RFC를 많은 회사가 Dodo Engineering에서는 RFC와 ADR을 모두 사용합니다. RFC 프로세스는 다음과 같습니다. 우리는 RFC 문서 초안을 작성했습니다. 소그룹으로 토론하고 의견을 모으고 조정했습니다. 그런 다음 RFC는 더 넓은 그룹에 전달되었습니다. 그런 다음 구현했습니다. 그 후 피드백을 수집하고 지표를 추적하고 결과를 평가했습니다. 릴리스 트레인의 RFC 문서 구조는 다음과 같습니다. 릴리스 트레인 프로세스에 대한 설명 어떤 팀이 참여하고 있으며, 무엇을 하고 있는지; 일정은 어떻게 될까요? 측정항목. RFC 초안을 작성할 때 우리는 다른 회사의 경험에 의존했습니다. 스카이스캐너 사운드클라우드 몬조 페이스북 첫 번째 구현 먼저 우리는 다음과 같은 프로세스를 생각해냈습니다. 매주 출시; 수요일 아침에 릴리스 브랜치를 생성합니다. 회귀를 완료하고 금요일에 검토를 위해 앱을 보냅니다. 월요일부터 릴리스를 시작합니다. 릴리스 팀: 기능 팀 중 하나에서 iOS 개발자 1명과 Android 개발자 1명, 2명의 QA 엔지니어. 수요일에 새로운 릴리스 브랜치를 생성합니다. 각 팀이 출시할 차례가 언제인지 나타내는 일정을 한 분기 전에 미리 작성하세요. 분기 후에 모여서 일정을 연장하세요. 개략적으로 우리의 릴리스 트레인은 다음과 같습니다. 모든 일이 순조롭게 진행되지는 않았습니다 한 달이 지나자 첫 경험은 좋았지만, 매주 회귀 작업을 수행하고 금요일까지 완료하는 것은 정말 어려웠습니다. 핫픽스를 적용할 시간이 없었고 가끔 그런 일이 발생하기도 했습니다. 2021년에는 회귀 테스트에 평균 3~4일이 걸렸습니다. 2022년에는 2~3일로 단축했지만 때로는 그 기간을 초과하기도 했습니다. 우리는 e2e 테스트를 통해 회귀 사례를 계속 다루었지만 아직 100% 다루지는 못했습니다. 우리는 각 플랫폼에서 각각 약 70%와 60%의 회귀 사례를 다루었습니다. 여기서 얻을 수 있는 점은 매주 릴리스 주기를 실행하는 것이 불편할 수 있다는 것입니다. 회귀 테스트를 완료하는 데 며칠이 걸리는 한 최종 답변 우리는 결국 2주 릴리스 주기로 전환했으며 이제 릴리스 트레인은 다음과 같습니다. 2주마다 출시; 수요일 아침에 릴리스 브랜치를 생성합니다. 회귀하고 금요일에 검토를 위해 앱을 보냅니다. 월요일부터 릴리스를 시작합니다. 릴리스 팀: 기능 팀 중 하나에서 iOS 개발자 1명과 Android 개발자 1명, 2명의 QA 엔지니어. 각 팀이 출시할 차례가 언제인지를 나타내는 일정을 한 분기 전에 미리 작성하세요. 분기 후에 모여서 일정을 연장하십시오. 릴리스를 점진적으로 롤아웃합니다. 필요한 경우 지금 시간이 있을 때 핫픽스를 수행하세요. 일주일 후 수요일에 새 릴리스 브랜치를 만듭니다. 모든 것이 계획대로 진행되는 경우 프로세스는 다음과 같습니다. 잠재적인 핫픽스를 위한 충분한 시간이 남아 있다는 점을 제외하면 모든 것이 주간 주기처럼 보입니다. 확장된 회귀 테스트의 경우 다음과 같습니다. 큰 문제도 아닙니다. 아직 핫픽스를 적용할 시간이 있습니다. 새로운 프로세스가 예측 가능성에 어떤 영향을 미쳤습니까? 우리의 주요 목표는 었습니다. 이는 두 부분으로 나눌 수 있습니다: 예측 가능성을 높이는 것이 신청서는 언제 출시되나요? 내 기능은 어느 릴리스에 포함되나요? 우리는 “언제 출시되나요?”라는 질문에 답했습니다. Release Train 프로세스를 구현하여 이제 각 팀은 "내 기능은 어느 릴리스에서 종료될 것인가?"라는 질문에 답할 수 있게 되었습니다. 기능을 계획하고 평가하는 순간에는 독립적입니다. 이전에는 다른 팀이 출시를 할 수도 있고 안 할 수도 있기 때문에 확실히 말할 수 없었습니다. 이제 모든 것은 그 팀의 계획에만 달려있습니다. 이를 더욱 확인하기 위해 우리는 모바일 개발자, QA 및 제품 관리자를 대상으로 설문조사를 실시했으며, 기타 질문과 함께 다음과 같은 질문을 했습니다. 다음 출시는 언제인가요? (이 질문에 100% 답변했습니다.) Release Train이 팀워크 계획에 도움이 되었나요? (75%가 긍정적으로 대답했지만 일부는 Release Train 없이도 자신의 작업을 완벽하게 예측했습니다.) Release Train은 코드 동결 및 릴리스 동결에도 도움이 되었습니다. 새해 전야(예: 9월 1일 및 일부 공휴일) 외에도 여러 가지 행사가 있었습니다. 이제 Release Train을 사용하면 릴리스 분기 생성, 회귀 테스트 등을 통해 이러한 날짜에 적응할 필요가 없습니다. 일정에 따라 작업을 릴리스합니다. 나중에 매장에서 열어보죠. 측정항목에 미치는 영향 단순히 문제를 해결하는 것 외에도 지표도 측정했습니다. 주요 내용을 살펴 보겠습니다. 리드타임 우리가 측정한 첫 번째 중요한 지표는 이었습니다. 출시에 대한 리드 타임 약속 이것이 그래프의 모습입니다. 저는 Release Train 프로세스를 시작한 지점을 화살표로 표시했습니다. 그래프를 보면 리드 타임이 약 6일 정도 단축된 것으로 나타났습니다. 6일은 긴 시간인가요, 짧은 시간인가요? 구글 벤치마크 있다 , 그러나 대부분 백엔드용입니다. 규모에 따라 다음 그룹을 구별합니다. 이 측정항목에 대한 Google의 벤치마크 엘리트: 1시간 미만 높음: 1시간~1주 중간: 1주~6개월 낮음: 6개월 이상 저는 표준 모바일 앱의 경우 리드 타임이 출시 주기의 절반을 이상적으로 목표로 삼아야 한다고 생각합니다. 이는 매일 작업을 메인 브랜치에 병합하는 것과 같습니다. 즉, . 출시 주기가 14일이라면 리드 타임은 7일을 목표로 해야 합니다 회귀당 버그 우리가 추적하는 또 다른 지표는 회귀당 버그 수입니다. 릴리스 후보가 얼마나 안정적인지 설명합니다. 이전 릴리스가 오래 전이었다면 잠재적으로 많은 수의 버그를 포함할 수 있는 새로운 코드를 많이 만들었을 것이며 회귀 및 수정에 더 많은 시간을 할애할 것입니다. 한때 이 측정항목에는 세 가지 버그가 있었습니다. 구체적인 숫자는 그다지 중요하지 않지만 전반적으로 추세가 하락한 것을 볼 수 있습니다. 더 많은 지표 Release Train의 일부로 어떤 지표도 모니터링했는지 간략하게 설명하겠습니다. 충돌이 없습니다. 우리는 항상 이 지표를 주시하고 있습니다. 회귀 분석을 더 빡빡한 기간에 맞추려는 시도로 인해 하락할 것이라는 가설이 있었습니다. 글쎄, 하락은 일어나지 않았습니다. 빈번한(주간) 릴리스가 고객 이탈 및 앱 삭제에 영향을 미칠지 궁금했습니다. 그 결과 아무런 영향도 발견되지 않았습니다. 구현, 개선 우리는 목표를 달성했다고 생각하는 현재 프로세스를 좋아합니다. 우리는 또한 이를 더욱 개선하는 방법도 알고 있습니다. 우리는 회귀를 더욱 간단하고 빠르게 만들기 위해 계속해서 자동화 작업을 진행하고 있습니다. 지금까지는 업무 자동화(브랜칭을 위한 스크립트) 부분을 생략했는데, 이 부분도 앞으로 큰 성장 포인트가 될 것 같습니다. 우리 앱은 20개국에서 작동하므로 애플리케이션을 다양한 언어로 번역해야 합니다. 이를 위한 내부 서비스가 있지만 개발자는 출시 전에 이 프로세스에 수동으로 참여해야 합니다. 이 프로세스를 자동화하면 잠재적으로 릴리스 주기가 더욱 향상될 수 있습니다. 요약 우리는 상대적으로 규모가 작았지만 릴리스 트레인이 필요하지 않았습니다. 릴리스, 크기, 개수를 예측할 수 없다는 사실에 직면했을 때 우리는 Release Train을 구현하기로 결정했습니다. 처음에는 주간 릴리스 주기를 시도했지만 회귀에 시간이 많이 걸리기 때문에 2주 릴리스 주기로 전환해야 했습니다. 우리는 그 이후로 계속 이런 식으로 살아왔습니다. 이제 우리는 릴리스를 예측할 수 있으며 지표는 긍정적인 역동성을 보여줍니다. e2e-test를 통해 회귀 사례의 적용 범위를 확대하고, 브랜치 작업 프로세스를 자동화하고, 번역 프로세스를 최적화할 계획입니다. 이 기사와 우리의 경험이 도움이 되기를 바랍니다. 특히 이미 유사한 문제에 직면했고 이로 인해 출시 프로세스에 대해 생각하게 된 경우라면 더욱 그렇습니다. 제 글을 읽어주셔서 정말 감사드립니다. 나는 당신이 그것을 즐겼기를 바랍니다. 질문이나 제안 사항이 있는 경우 댓글로 한 줄 남겨주시면 꼭 읽어보겠습니다! 그리고 . 주로 안드로이드 개발과 소프트웨어 엔지니어링 전반에 대해 포스팅합니다. 트위터에서 나를 팔로우하세요 게시됨 여기에도
