DevOps 프로세스: 소규모 배치 작업

소규모 배치 작업은 피드백 루프가 중요하거나 어떤 결정이 가져오는 결과를 보면서 빠르게 배우려는 모든 분야에서 필수적인 원칙입니다. 소규모 배치로 작업하면 특정 개선사항이 원하는 효과를 낼 수 있는지 신속하게 테스트할 수 있으며, 원하는 효과를 얻을 수 없다면 가정을 바로잡거나 다시 논의할 수 있습니다. 이 문서는 조직의 혁신 및 프로세스 개선을 포함한 모든 유형의 변경사항에 적용되지만 주로 소프트웨어 배포에 중점을 둡니다.

소규모 배치 작업은 린 제품 관리의 한 방식입니다. 소규모 배치 작업은 가치 흐름에서의 작업 가시성, 팀 실험, 고객 의견에 대한 가시성과 같은 기능과 함께 소프트웨어 제공 성능과 조직 성과를 예측합니다.

작업이 대규모 배치로 수행되는 한 가지 이유는 변경사항 이관 시 고정 비용이 많이 들기 때문입니다. 기존의 단계별 소프트웨어 개발 접근법에서는 개발에서 테스트로, 테스트에서 IT 운영으로 이관하는 과정이 완전한 릴리스로 구성됩니다. 이는 수십, 수백 명으로 구성된 팀이 진행하는 데 수개월 걸리는 작업입니다. 이러한 기존의 접근법으로 변경사항에 대한 피드백을 수집하려면 몇 주 또는 몇 개월이 걸릴 수 있습니다.

이와 반대로, 여러 부서의 팀과 간단한 접근법을 활용하는 DevOps 방식에서는 소프트웨어 개발부터 테스트, 운영을 거쳐 프로덕션까지 몇 분이면 끝납니다. 그러나 이처럼 빠른 진행을 위해서는 소규모 배치로 코드를 작성해야 합니다.

소규모 배치로 작업하면 많은 이점이 있습니다.

  • 변경사항에 대한 피드백을 받는 데 걸리는 시간이 단축되어 문제를 보다 쉽게 분류하고 조치할 수 있습니다.
  • 효율이 높아지고 의욕이 고취됩니다.
  • 조직이 매몰 비용 오류에 사로잡히지 않도록 합니다.

기능 및 제품 수준에서 소규모 배치 접근법을 적용할 수 있습니다. 예를 들어 최소 기능 제품, 즉 MVP는 제품 및 비즈니스 모델에 대한 검증된 학습을 지원하는 충분한 기능을 갖춘 제품의 프로토타입입니다.

지속적 배포는 소규모 배치로 작업 시 빌드되며 버전 제어의 모든 변경사항을 가능한 빨리 가져오려고 합니다. 지속적 배포의 목표는 소규모 배치로 작업하기 유용하게 소프트웨어 배포 프로세스의 경제학을 바꾸는 것입니다. 이 접근법은 팀에 빠르고 포괄적인 피드백을 제공하여 업무를 개선할 수 있습니다.

소규모 배치로 작업하는 방법

새로운 기능을 계획할 때 개별적으로 단기간에 완료할 수 있는 작업 단위로 쪼개 보세요. 각 기능 또는 작업 배치는 INVEST 원칙의 애자일 개념을 따르는 것이 좋습니다.

  • Independent(독립적). 작업 배치를 다른 배치와 가능한 한 독립적으로 만들어서 팀이 다른 작업 배치와 독립적으로 해당 배치를 배포하고 검증할 수 있도록 합니다.
  • Negotiable(절충 가능). 각 작업 배치는 반복 가능하며 피드백이 수신되면 절충할 수 있습니다.
  • Valuable(가치 있는). 개별 작업 배치가 유용하며 이해관계자에게 가치를 제공합니다.
  • Estimable(추정 가능한). 범위를 쉽게 추정할 수 있는 작업 배치에 대한 충분한 정보가 있습니다.
  • Small(소규모). 스프린트 중에 몇 시간에서 며칠을 의미하는 작은 시간 단위로 작업 배치를 완료할 수 있어야 합니다.
  • Testable(테스트 가능). 각 작업 배치를 사용자가 기대하는 방식으로 작업하면서 테스트, 모니터링, 검증할 수 있습니다.

기능의 크기가 적절한 경우 기능 개발 작업을 더 작은 배치로 분할할 수 있습니다. 이 프로세스는 어려울 수 있으며 개발 경험이 필요합니다. 개발자는 릴리스 가능한 소규모 변경사항 여러 개를 최소한 하루에 한 번 트렁크로 체크인하는 것이 이상적입니다.

핵심은 UI 레이어가 아닌 서비스 또는 API 레이어에서 개발을 시작하는 것입니다. 이렇게 하면 앱 사용자가 초기에 사용할 수 없는 API를 추가하고 해당 변경사항을 트렁크로 체크인할 수 있습니다. 이러한 변경사항을 사용자에게 표시하지 않고 프로덕션으로 넘겨줄 수 있습니다. 다크 런칭이라고 하는 이 접근법을 통해 개발자는 완료된 소규모 배치와 아직 완전하지 않은 기능을 코드에 체크인할 수 있습니다. 그런 다음 이러한 변경사항에 대한 자동 테스트를 실행하여 변경사항이 예상대로 동작하는지 입증할 수 있습니다. 이렇게 하면 팀이 계속 빠르게 작업하면서 장기 지속 기능 분기가 아닌 트렁크를 개발할 수 있습니다.

또한 구성 설정에 기반을 둔 조건문인 기능 전환을 사용하여 변경사항 다크 런칭을 수행할 수도 있습니다. 예를 들어 UI 요소를 표시하거나 보이지 않게 하거나 서비스 로직을 사용 설정 또는 중지할 수 있습니다. 기능 전환 구성은 배포 시 또는 런타임 시 읽을 수 있습니다. 이러한 구성 설정을 사용하여 스택의 더 아래쪽에서 새 코드의 동작을 전환할 수 있습니다. 또한 장기 지속 기능 분기를 사용하지 않고 트렁크 기반 개발 및 출시를 계속하면서 추상화된 분기라고 하는 유사한 기법을 사용하여 시스템에 더 큰 규모의 변경사항을 적용할 수 있습니다.

이 접근법에서는 작업 배치가 프로덕션에 배포되고 피드백 프로세스가 변경사항 검증을 시작해야만 작업 배치가 완료됩니다. 피드백은 사용자, 시스템 모니터링, 품질 보증, 자동 테스트를 포함한 여러 소스에서 다양한 형태로 제공됩니다. 목표는 속도에 맞게 최적화하여 사용자에게 변경사항이 전달되는 사이클 타임을 줄이는 것입니다. 이렇게 하면 가설을 최대한 빨리 검증할 수 있습니다.

소규모 배치 작업의 일반적인 단점

작업을 소규모 배치로 쪼개면 두 가지 단점이 발생합니다.

  • 작업이 충분히 작은 조각으로 쪼개지지 않음. 첫 번째 과제는 작업을 의미 있는 방식으로 쪼개는 것입니다. 기능 상태와 상관없이 코드를 커밋하고 개별 기능을 며칠 내로 개발하는 것이 좋습니다. 완료하고 확인하는 데 일주일 이상 걸리는 코드 배치는 너무 큽니다. 개발 프로세스 전체에서 아이디어를 반복적으로 개발할 수 있는 단위로 쪼개는 방법을 분석해야 합니다.

  • 소규모 배치로 작업하고 배치를 다시 그룹화한 후 테스트 또는 릴리스를 위해 다운스트림으로 전송. 이러한 방식으로 작업을 다시 그룹화하면 변경사항에 결함이 있는지 여부와 사용자와 조직이 처음부터 변경사항을 적용하는 데 동의했는지 여부에 대한 피드백이 지연됩니다.

작업 배치의 크기를 줄이는 방법

작업을 몇 시간 내에 완료할 수 있는 작은 배치로 분할하면 일반적으로 해당 배치를 1시간 이내로 테스트하고 프로덕션에 배포(PDF)할 수 있습니다. 핵심은 브랜치에서 복잡한 기능을 개발하여 가끔 릴리스하는 것이 아니라 신속한 개발이 가능한 작은 기능으로 작업을 분해하는 것입니다.

소규모 배치 개발을 개선하려면 환경을 확인하고 다음 조건을 충족하는지 확인하세요.

  • 팀이 프로덕션 릴리스를 더 자주 수행할 있도록 작업이 분해되었습니다.
  • 개발자는 작업을 며칠이 아닌 몇 시간 안에 완료할 수 있는 소규모 변경사항으로 나눈 경험이 있습니다.

소규모 배치 개발에 전문가가 되려면 모든 개발팀에서 이러한 각 조건을 충족하도록 노력해야 합니다. 이는 지속적 통합트렁크 기반 개발 모두에 필요한 조건입니다.

작업 배치의 크기를 측정하는 방법

지속적 통합모니터링을 이해했으면 시스템 및 개발 환경에서 소규모 배치 개발을 측정할 수 있는 방법을 대략적으로 설명할 수 있습니다.

  • 애플리케이션 기능을 자주 릴리스 가능한 방식으로 분해합니다. 릴리스는 얼마나 자주 가능하나요? 팀마다 이 릴리스 주기가 어떻게 다른가요? 프로덕션에 대규모 기능과 관련된 지연이 발생하나요?
  • 개발자가 일주일 이내로 작업을 완료할 수 있도록 애플리케이션 기능을 분할합니다. 일주일 이내로 완료할 수 있는 기능의 비율은 얼마인가요? 일주일 이내로 완료할 수 없는 기능은 무엇인가요? 기능이 완료되기 전에 변경사항을 커밋하고 릴리스할 수 있나요?
  • MVP를 정의하고 팀의 목표로 설정합니다. 작업이 복잡하고 긴 프로세스가 아닌 MVP와 빠른 개발이 가능한 기능으로 분해되었나요?

측정값은 다음에 따라 다릅니다.

  • 조직의 프로세스 파악
  • 낭비를 줄이기 위한 목표 설정
  • 개발 프로세스에서 복잡성을 줄이는 방법 찾기

다음 단계