가이드: 소규모 팀을 위한 소프트웨어 릴리스 관리

릴리스 관리 프로세스의 공식화(있는 경우)

일부 팀 구성, 특히 신생 기업에서 볼 수 있는 구성에는 새 버전의 제품을 출시할 때 지원을 제공할 DevOps나 인프라 엔지니어가 없습니다.

게다가 정의된 공식 프로세스가 있는 관료주의적인 대기업과 달리 스타트업의 CTO 또는 소프트웨어 개발 팀장은 소프트웨어 릴리스 관리 프로세스의 복잡성을 인식하지 못하는 경우가 많습니다. 회사의 일부 개발자는 프로세스의 복잡한 세부 사항을 알고 있을 수 있지만 모든 사람은 아닙니다. 이 지식을 철저히 문서화 하지 않으면 혼란을 초래할 수 있다고 생각합니다.

이 기사에서는 특히 개발자의 관점에서 릴리스 프로세스를 공식화하는 방법에 대한 몇 가지 팁을 제공하려고 합니다.

소프트웨어 릴리스 체크리스트 입력

Atul Gawande의 책인 Checklist Manifesto 에 따르면 일부 작업에 대한 체크리스트라는 개념에 익숙할 것입니다. 저는 공식 릴리스 프로세스(소프트웨어 개발 세계의 다른 많은 작업과 마찬가지로)가 개발자에게 이 프로토콜을 구현할 기회를 제공한다고 믿습니다. 릴리스 프로세스 체크리스트는 공유 문서에 보관해야 하며 가급적이면 공동 작업 위키 형식이나 Google 드라이브의 스프레드시트 형식으로 보관해야 합니다.

이 중요한 문서를 팀과 공유하고 편집 권한을 부여함으로써 모든 구성원은 공식적으로 정의된 릴리스 프로세스에 액세스할 수 있습니다. 이를 통해 프로세스가 어떻게 작동하는지 이해할 수 있습니다. 또한, 다른 팀원들과의 토론을 통해 팀이 때때로 이를 개선할 수 있는 권한을 부여합니다. 이를 통해 투명성을 확보하고 전체 팀이 릴리스 동안 진행 중인 일, 완료한 단계 및 완료한 단계에 대한 실시간 액세스를 허용해야 합니다.

이 스프레드시트를 보고 이해 관계자는 단계의 결과에 따라 '진행' 또는 '진행 금지'를 결정할 수 있습니다. 예를 들어, 테스트 환경에서 스트레스 테스트가 잘못되면 프로젝트 관리자가 프로덕션 릴리스를 취소하기로 결정할 수 있는 이벤트를 기반으로 합니다.

기초로 사용하기 위한 제안된 단계

이 섹션에서는 릴리스 프로세스에 대한 자체 체크리스트를 작성하는 데 사용할 수 있는 몇 가지 단계를 제안합니다. 이러한 단계 중 일부 는 의무 사항이 아닙니다 . 앱마다 다르고 조직마다 다른 방식으로 작동하므로 자유롭게 조정하고 워크플로에 더 잘 맞도록 변경하세요.

1. 릴리스 분기 생성

이전 블로그 게시물에서 설명한 주제인 Git Workflow의 개념이나 릴리스 분기의 개념에 익숙할 것입니다.

이상적으로는 최소한 세 개의 분기가 있어야 합니다.

• master : 프로덕션 환경의 현재 상태를 반영해야 합니다. 마스터 에 대한 모든 새 커밋은 새 릴리스로만 구성되어야 합니다.
• 개발 : 이 분기에는 완성된(및 테스트된) 예정된 기능이 포함되어야 합니다. 각 기능에 대해 별도의 분기를 만든 다음 기능이 준비되면 이를 병합하여 개발 하는 것이 일반적입니다.
• 릴리스 : 릴리스 분기는 프로덕션으로 보낼 준비가 된 커밋 모음과 릴리스와 관련된 몇 가지 추가 사소한 버그 수정입니다.

릴리스가 완료되면 릴리스 분기를 제거해야 하므로 항상 동일한 master 또는 developer 와 달리 이러한 분기가 생성되고 항상 소멸된다는 점에 유의하십시오.

새 릴리스 분기를 생성하려면 git 터미널의 개발 분기에서 다음을 입력합니다.

$ git checkout -b release/xyz

위에서 정의한 것과 같은 명명 규칙을 사용하여 필요에 따라 xyz를 major.minor.patch 버전 번호로 바꾸는 것이 편리합니다(팀 내에서 정의하고 준수해야 하는 정책입니다).

또한 일부 버그 수정을 릴리스 분기에 코딩하는 경우 이를 다시 개발 에 병합하는 것을 잊지 말아야 합니다. 릴리스 분기의 주요 목적은 앱이 프로덕션에 들어간 후 어떻게 작동해야 하는지에 대한 미리보기 스냅샷을 갖는 것입니다.

2. 범프 버전

다음 단계는 릴리스 분기에서 버전 번호를 범프(수정 또는 증가)하는 것입니다.

AndroidManifest.xml / package.json / pom.xml / 또는 앱 버전이 프로젝트에 저장된 모든 위치(YMMV)를 열고 버전 번호를 업데이트한 다음 변경 사항을 현재 릴리스 분기에 커밋해야 합니다.

두 가지 이유로 버전 번호를 업데이트하는 것이 중요합니다.

첫째, 각 버전에 도입된 기능을 추적하고 매핑할 수 있으며, 둘째, 문제 해결을 수행하거나 지원을 위해 연락해야 하는 경우 사용 중인 버전을 알 수 있습니다. 모바일 앱을 빌드하는 경우 이 단계에서 업데이트하는 버전 번호는 일반적으로 사용자 측, 정보 섹션 또는 Google Play 또는 Apple App Store 에 표시됩니다. 이 단계는 또한 환경에 따라 업데이트할 수 있는 좋은 기회입니다. - 구성 파일(별도의 리포지토리에 보관하는 것이 좋습니다)

마지막으로 릴리스 분기를 원본으로 푸시하여 다른 개발자가 사용할 수 있도록 하는 것이 좋습니다.

$ git push -u origin release/xyz

3a. 릴리스 분기를 마스터에 병합하고 태그 지정

프로덕션에는 마스터 브랜치만 배포해야 하므로 이 단계에서는 릴리스 브랜치를 master 에 병합해야 합니다.

 $ git checkout master $ git merge --no-ff release/xyz $ git push

--no-ff 플래그는 선택 사항이지만 빨리 감기 기술을 사용하여 병합을 완료할 수 있더라도 새 커밋 개체를 강제로 생성하려면 이 플래그를 사용하는 것이 좋습니다.

다음으로 마스터 브랜치에서 릴리스에 태그를 지정할 차례입니다.

$ git tag -a xyz -m 'description of new version, features or fixes included'

태그는 git 저장소에 기록의 이 특정 지점을 유지하고 나중에 다시 돌아와서 특정 태그에서 별도의 분기를 다시 만들 수 있기 때문에 유용합니다.

3b. 풀 리퀘스트를 사용하여 릴리스 브랜치 병합

자주 사용되는 또 다른 대안은 풀 요청 을 사용하여 릴리스 분기를 master 로 병합하는 것입니다.

이 접근 방식에는 많은 이점이 있습니다. 팀이 다양한 릴리스 관련 문제를 논의하는 데 사용할 수 있는 협업을 위한 새로운 공간이 생성됩니다. 이 시점은 코드 검토 프로세스를 통합하기 위한 추가 게이트를 추가하는 동시에 도입될 코드를 모니터링하고 잠재적인 수정 사항에 대해 논의하기 위해 더 많은 관심을 가질 수 있는 좋은 시간입니다.

끌어오기 요청을 워크플로에 구현할 수 있는 일부 도구는 GitHub, Bitbucket 및 GitLab입니다(후자의 경우 병합 요청이라고 함). 이 도구를 사용하면 git 명령을 수동으로 입력하지 않고 대신 웹 인터페이스를 사용하여 소스 분기( release )와 대상 분기( master )를 설정한 다음 한 명 이상의 검토자를 추가합니다. 이러한 새로운 변경 사항에 대한 인라인 주석을 작성하고 개선 사항을 제안하는 등의 작업을 수행할 수 있습니다.

모든 검토자가 pull 요청을 승인한 후 UI의 버튼을 눌러 변경 사항을 자동으로 마스터 에 병합할 수 있습니다.

4. 프로덕션 환경에 마스터 배포

이 단계에서 앱을 배포하기 전에 팀의 테스터가 연기 테스트 (별도의 체크리스트에서 정의할 수 있음)를 하도록 하는 것이 좋습니다. 마스터 브랜치를 별도의 테스트 환경에 배포하는 것이 좋습니다. 그런 다음 테스터는 몇 가지 기본 작업을 수행하여 최신 빌드에서 병합한 후 아무 문제가 없는지 확인할 수 있습니다. 연기 테스트를 수행하는 방법은 이 기사의 범위를 벗어나지만 웹에서 이에 대한 많은 자료를 찾을 수 있습니다. 연기 테스트의 결과는 릴리스 체크리스트/스프레드시트에 통합되어 잘못된 것을 문서화할 수 있습니다.

이 시점에서 변경 사항을 배포하고 적용할 준비가 되었습니다. 계속해서 마스터 브랜치를 배포하십시오. 이 단계는 사용 중인 인프라 스택에 따라 다릅니다. 앱을 업로드하기 위해 Amazon EC2 인스턴스에 연결하거나 Heroku 리모컨으로 푸시하거나 ssh를 통해 VPS에 연결하여 새 버전 또는 기타 프로세스를 복사하는 작업이 포함될 수 있습니다.

앱이 업로드된 후 성공적으로 배포되었고 예상대로 작동하는지 확인합니다.

5. 다시 개발 로 병합하고 릴리스 분기 삭제

이제 릴리스가 거의 완료되었습니다. 릴리스 분기를 development 로 병합하여 후자의 버전 번호를 업데이트하고 모든 버그 수정을 기본 개발 분기로 전송하려고 합니다.

 $ git checkout develop $ git merge release/xyz

이제 릴리스 분기를 제거할 시간입니다.

$ git branch -d release/xyz

6. 변경 로그 생성

프로젝트 루트에 CHANGELOG.md(또는 이에 상응하는 파일)라는 파일이 있어야 하며, 버그 수정, 새로운 기능, 버그 수정, 새 기능 등 포함된 모든 내용을 문서화하기 위해 새 릴리스가 있을 때마다 새 항목을 추가해야 합니다. 알려진 문제 및 릴리스 정보 형식의 기타 관련 정보. 이것은 사용자와 기여자가 프로젝트의 각 릴리스(또는 버전) 간에 어떤 변경 사항이 있는지 확인하는 데 정말 유용합니다 .

변경 로그 항목에는 날짜, 버전 번호 및 릴리스에 대한 몇 가지 참고 사항이 포함됩니다. 항목은 역순으로 보관해야 합니다. 다음은 프로젝트에 적용할 수 있는 간단한 템플릿입니다.

 <app's name or component released> <version xyz> | <date> <developer's name in charge of release> | <developer's email> Features: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Bugs fixed: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Enhancements: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Optional: known issues plus other release notes.

또한 이 단계는 git 로그를 트래버스하고 변경 로그 항목을 자동으로 생성하는 기본 스크립트를 코딩하거나 다음과 같이 동일한 작업을 수행하는 도구를 사용하여 완전히 자동화할 수 있습니다.

• Skywinder의 Github Changelog 생성기,
• fojuth의 ReadmeGen
• github-changes, lalitkapoor 작성

그러나 자동화 정도는 커밋 메시지 형식의 엄격함에 직접 비례한다는 점을 명심하십시오. 팀과 커밋 메시지의 특정 형식에 동의하는 것이 항상 좋은 습관이라고 생각합니다. 커밋 메시지 스타일에 대한 지침을 따르면 구문 분석이 더 쉬워지고 변경 로그 생성을 자동화할 가능성이 높아집니다.

7. 이해관계자와의 커뮤니케이션

여기에서 일반적으로 다음 중 일부를 수행합니다.

• 내부 메시징 도구(예: Slack)를 통해 새 릴리스가 완료되었음을 팀에 알립니다. 릴리스 관련 이벤트를 전달할 목적으로만 새 채널(예: #releases )을 만드는 것이 좋습니다. 조치를 취한 후 메시지를 게시하기 위해 Slack 채널에 후크를 쉽게 추가할 수 있습니다.
• 또는 변경 로그에 대한 링크 또는 변경 로그 파일이 첨부된 이메일을 이해 관계자에게 보냅니다.
• 블로그 게시물(앱 또는 제품에 대한 블로그가 있는 경우) 또는 트윗을 작성합니다.

조직의 특성에 따라 더 많은 조치를 취할 수 있습니다. 중요한 것은 제품의 새 버전을 사용할 수 있음을 알리는 것을 잊지 않는 것입니다.

8. 이슈 트래커 정리

릴리스가 실행된 후 현재 프로덕션 중인 버그 수정 또는 기능을 추적하기 위해 일부 티켓의 상태를 업데이트해야 할 수도 있습니다. 일반적으로 여기에는 일부 태그 변경이 포함됩니다(소규모 프로젝트의 경우 릴리스가 완료된 후 제거하는 릴리스 보류 태그를 사용합니다).

각각의 새 버전에 대해 이정표를 사용하는 경우 상태를 업데이트하거나 완료로 표시해야 할 수 있습니다. 일부 이슈 트래커를 사용하면 릴리스를 계획하고 스프린트와 정렬하고 버그가 릴리스를 차단하는지 여부 및 기타 유용한 정보를 추적할 수도 있습니다.

그것은 모두 도구를 사용하는 방법에 달려 있습니다. 문제 추적기의 정보를 업데이트하는 작업이 릴리스 체크리스트에 포함되어야 한다는 점을 지적하고 싶습니다.

릴리스 프로세스 자동화 정보

독자는 위에서 설명한 변경 로그 단계 외에도 앞서 언급한 많은 단계도 자동화할 수 있다는 사실을 알아차렸을 것입니다.

릴리스 프로세스의 일부를 자동화하는 기능은 큰 이점이며 많은 시간을 절약합니다. 스크립트를 만들거나 개별 단계를 자동화한 다음 지속적 전달 목표를 달성하는 방법을 알아내는 것이 좋습니다. 지속적 배포는 위험을 줄이고 비용을 줄이며 개발자가 릴리스 관리에 소요해야 하는 시간을 줄일 수 있습니다. 결과적으로 더 자주 릴리스할 수 있고 개발에 할당된 시간 측면에서 생산성을 높일 수 있습니다.

DevOps 회사의 성배는 릴리스 프로세스를 자동으로 트리거하는 버튼(또는 명령 실행)을 눌러 새 버전을 출시할 수 있다는 것입니다. 지정된 시간. 물론 많은 테스트 프로세스를 자동화해야 하기 때문에 달성하기 어렵지만 불가능한 것은 아닙니다.

모범 사례 수용

이 섹션에서는 릴리스 프로세스를 보다 원활하게 하거나 문제가 발생할 경우 안전 조치를 취하기 위해 내가 편리하다고 생각한 몇 가지 권장 방법을 설명하겠습니다.

릴리스를 수행하기에 가장 적합한 날짜를 찾으십시오.

나는 보통 목요일 정오부터 업무 마감 사이에 작업 중인 앱을 출시합니다.

월요일부터 금요일까지 일한다면 금요일에 시작하는 것은 좋은 생각이 아닙니다. 릴리스 후 문제가 발생하면 월요일까지 고칠 시간이 없습니다(주말에 일하지 않는 한). 목요일에 릴리스하는 것이 더 편리한 이유입니다. 금요일에는 배포된 후 새 버전을 모니터링하고, 문제를 수정하거나, 롤백을 수행할 수 있기 때문입니다.

웹 앱을 관리하는 경우 언급해야 할 또 다른 중요한 사항은 대부분의 사용자가 위치한 시간대를 아는 것입니다. 트래픽이 적은 기간 동안 릴리스 시간을 정하여 문제가 발생할 경우 잠재적인 피해를 최소화해야 합니다. 때로는 사용자 기반이 전 세계에 퍼져 있을 때 이것이 까다로울 수 있지만 어쨌든 몇 가지 조사를 수행하고 최적의 시간을 결정해야 합니다.

새 릴리스 전에 데이터베이스 백업

정기적인 DB 백업이 없는 경우 릴리스 프로세스에 단계를 추가하여 릴리스를 시작하기 전에 백업을 수행하는 것이 좋습니다.

단계적 출시

게시자가 새 기능을 출시했다고 발표했을 때 해당 기능을 휴대전화에서 사용할 수 있게 되기까지 며칠 또는 몇 주가 걸리는 이유가 궁금하신가요? 많은 회사에서 단계적 출시를 사용하기 때문입니다.

페이스북은 오래전부터 이 일을 해왔습니다. 5~10%의 사용자를 대상으로 새로운 기능을 테스트하고 사용자 기반의 100%에 도달할 때까지 점차적으로 기능을 늘립니다. 단계적 출시 단계에서 사용자 피드백과 충돌 보고서를 자세히 살펴봐야 합니다. 이 정보를 사용하여 모든 사용자에게 영향을 미치기 전에 릴리스를 연기하거나 오류를 수정할 수 있습니다.

Android 개발자 콘솔에는 Android 앱용 단계적 출시를 구현하는 멋진 도구가 있습니다.

지속적인 통합

지속적 통합은 여러 가지 이유로 수용할 가치가 있는 관행입니다. 첫째, 실수를 조기에 감지하여 성공적인 릴리스 비율을 높일 수 있습니다. 둘째, 앞서 설명한 대로 지속적 전달과 완전 자동화를 구현하기 전의 논리적인 첫 번째 단계입니다.

Martin Fowler는 지속적 통합의 열렬한 지지자입니다. 그는 이 방법을 사용할 때 릴리스 프로세스에 추가할 수 있는 엄청난 양의 이점에 대해 설명합니다. 이것은 큰 주제이며 이에 대한 많은 책과 블로그 게시물이 있으며, 귀하의 작업에 훨씬 더 많은 자신감을 줄 것이라고 믿기 때문에 여기에 언급합니다. CI 사용의 많은 이점 중에서 위험 감소, 작동 중인 것과 작동하지 않는 것을 식별할 수 있는 가시성 증가, 버그 조기 감지, 배포 빈도 증가 등을 발견할 수 있습니다.

CI 구현의 시작점은 "지속적 통합 서버"를 설정하는 것입니다. 시도해 볼 수 있는 몇 가지 좋은 도구는 CruiseControl, Bamboo, Jenkins 및 Travis입니다.

Exitlude: 모든 것이 해결될 것입니다

공격적으로, 우리 모두는 우리가 맡은 역할을 방어합니다 유감스럽게도, 시간이 당신을 당신의 길로 보낼 것입니다 우리는 모든 것을 보았습니다, 신뢰의 모닥불, 플래시의 고통 모두 운동

엑시트루드, 더 킬러

마무리로, 복잡성, 사용자 기반 또는 조직의 규모에 관계없이 앱에 대해 잘 정의된 출시 프로세스를 갖는 것이 매우 중요하다고 말씀드리고 싶습니다.

그렇지 않은 경우 이 가이드 및 이와 유사한 다른 가이드를 사용하여 몇 가지 기본 단계에 대해 생각하고 팀과 브레인스토밍하여 첫 번째 초안을 작성하는 것이 좋습니다. 다음 릴리스에서 시도하고 반복하십시오. 결국 자신의 릴리스 프로세스를 구축하게 됩니다.

그런 다음 프로세스의 일부를 자동화 하는 방법에 대해 생각하기 시작합니다. 개선할 수 있는 부분에 대해 생각해 보세요. 작은 최적화를 통합하여 릴리스 시간을 줄이는 방법을 탐색합니다. 자동화는 궁극적인 목표가 되어야 합니다. 그러나 처음부터 계획하지 마십시오. 그렇지 않으면 큰 도약을 시도하여 실패할 것입니다. 모든 과정과 마찬가지로 점진적으로 개선하는 것이 좋습니다.

앱의 새 버전을 출시할 때 사용하는 다른 트릭이나 지침이 있습니까? 그렇다면 알려주세요. 저는 DevOps 세계에서 오지 않았습니다. 저는 우연히 꽤 조직적이고 구조화된 개발자일 뿐입니다. 그러나 많은 베테랑들에 비해 저는 아직 이 면에서 초보자입니다. 추가할 사항입니다.