팀의 릴리스 프로세스
DevOps 방식을 설정하기 위한 첫 단계는 현재 프로세스를 평가하는 것입니다. 즉, 다음을 분석합니다.
- 배포 패키지 및 NuGet과 같은 기존 아티팩트와 컨테이너 리포지토리입니다.
- 기존 테스트 관리 도구
- 기존 작업 관리 도구
- 마이그레이션 및 통합 전략 권장
Tailspin 팀과 함께 평가해 보고, DevOps가 어떤 도움이 되는지 알아보겠습니다.
제품 관리자 Irwin이 떠난 후 Amita가 말합니다. "우리는 도움이 필요해요. 언제까지 해결책을 마련해야 하는지는 모르겠지만 시간이 얼마 없다는 건 알아요. 문제를 빨리 해결할 준비가 되어 있지 않아요. 게다가 우리가 이런 문제를 해결하지 않으면 새로운 Space Game 웹 사이트를 공개할 수 없는데, 게임 개발은 빠르게 진행되고 있어요.”
Andy가 Mara를 보며 말합니다. “처음 몇 주 동안 완료하기에는 힘든 일이네요.”
"괜찮아요."라고 Mara가 대답합니다. "일이 어떻게 돌아가고 있는지 제게 설명해 주셨으면 좋겠어요. 게임이 개발 단계에서 프로덕션 단계로 어떻게 이전되나요?"
"좋은 질문이네요."라고 Andy가 말합니다. “최대한 간단히 답해 드려 볼게요.”
팀은 휴식을 취하면서 비공식 토론을 나누기 위해 커피 전문점으로 가기로 합니다. 왜 그렇게 많은 문제가 생겼는지 함께 파악할 것입니다.
Mara는 커피를 마시며 이야기를 듣고 메모합니다. 정리되지 않은 많은 정보를 주고받습니다. 팀에 대한 그녀의 전반적인 생각은 이렇습니다.
- 폭포 접근법을 사용합니다. 경영진이 우선순위를 정합니다. 개발자가 코드를 작성하고 QA 팀에 빌드를 전달합니다. QA 팀이 테스트한 후 배포를 위해 운영 팀에 빌드를 전달합니다.
- 폭포 접근법은 소규모 팀에서는 적합하지만 이 팀에서는 목표가 항상 분명한 것은 아니며, 자주 변경되는 것처럼 보입니다.
- 테스트가 프로세스 후반까지 지연됩니다. 즉, 버그를 수정하고 변경 사항을 적용하기가 더 어렵고 비용이 많이 듭니다.
- 여기서 완료의 정의가 분명하지 않습니다. 팀원에게는 각자의 아이디어가 있습니다. 모두가 원하는 종합적인 비즈니스 목표가 없습니다.
- 일부 코드는 중앙 집중식 버전 제어 시스템에 있습니다. 많은 도구와 스크립트가 네트워크 파일 공유에만 존재합니다.
- 여러 수동 프로세스가 있습니다.
- 커뮤니케이션은 마구잡이식이며, 이메일, Word 문서 및 스프레드시트를 통해 이루어집니다.
- 피드백도 간헐적이고 일관적이지 않습니다.
- 긍정적인 점은 팀이 잘 지내고 있고, 개선할 의지가 있다는 것입니다.
Mara는 쌓여 있는 메모를 보고 이러한 모든 정보를 정리해야 한다는 것을 알게 될 것입니다. 정보를 정리하면 프로세스를 평가하기가 한결 쉬워질 것입니다. 그녀는 DevOps 접근법이 팀의 여러 문제를 해결해 주겠다고 확신했지만 팀에게 자신의 사례를 발표할 방법이 필요했습니다.
DevOps 방식은 기존 프로세스에 대한 이해로 시작되는 경우가 많습니다. 그리고 나서 잘되고 있는 점, 잘 안 되는 점을 평가하고, 먼저 해결해야 할 문제에 초점을 맞출 수 있습니다.
Mara가 이렇게 묻습니다. "가치 흐름도 작성 연습을 해보신 분이 있나요?"
Andy는 눈을 희번덕거렸고, Amita는 한숨을 쉬었고, Tim은 이렇게 말했습니다. "더 이상의 서류 작업은 필요 없어요."
Mara가 말합니다. "알겠습니다. 제게 맡기세요."
팀원 전원은 신입 직원에게 일을 맡기고 다시 사무실로 돌아갑니다.