일하면서 언젠가는 모놀리식 소프트웨어 릴리스에 참여하게 되거나 이미 참여했을 것입니다. 이는 까다로운 버그와 상호 의존성이 있는 소프트웨어 릴리스이며 팀 전체가 24시간 내내 대기해야 합니다. 프로덕션으로 이동하면 여러 패치가 필요할 수 있다는 사실은 말할 것도 없습니다.
코드 제공, 즉 소프트웨어 릴리스는 소프트웨어 개발자의 애질리티를 보여주는 강력한 지표입니다. 릴리스 프로세스가 원활하지 않다면 계획, 코딩 및 테스트 작업을 더 빠르게 하기 위한 노력은 모두 허사가 됩니다. 바로 이러한 이유로 인해, 애자일 팀과 DevOps 팀은 자동화로 전환하고, 개발 단계 초기에 개발과 운영을 통합하고, 지속적 통합을 실행하며, 결함을 즉시 해결해야 합니다.
코드를 릴리스 가능한 상태로 유지하는 것은 애자일 개발의 특징입니다. 준비가 되었다고 판단한 순간 코드를 바로 제공할 수 없다면 린 계획과 반복적인 개발은 모두 의미가 없어집니다.
훌륭한 소프트웨어 릴리스는 모듈식 아키텍처로 시작합니다
어떤 소프트웨어 프로그램이든 소프트웨어를 쉽게, 그리고 자주 릴리스하는 것이 가장 좋습니다. 팀은 모듈식 아키텍처를 구축(또는 리팩토링)하여 릴리스를 애자일 문화의 자연스러운 부분으로 만들 수 있습니다. 위에 나온 모놀리스와 같은 하나의 대규모 애플리케이션을 사용하는 대신, 프로그램 초기에 여러 부분으로 모듈화하세요.비슷한 기능을 더 작은 애플리케이션 또는 컴포넌트로 그룹화하고 각 애플리케이션과 컴포넌트 간에 명확한 API 계약을 맺으세요. API는 모든 빌드에서 자동으로 테스트가 이루어져 호환성이 보장되고 소프트웨어 릴리스의 위험이 줄어듭니다.
모듈식 아키텍처에서는 "빅뱅 스타일" 릴리스에서 전체 소프트웨어 스택을 릴리스할 필요가 없으며, API 계약을 통해 손쉽게 컴포넌트를 업데이트하고 버전 간의 호환성을 보장할 수 있습니다. 간단히 말하자면, 모듈식 소프트웨어 릴리스에는 변동 사항이 덜 필요합니다. 그리고 이는 곧 더 간단한 릴리스를 의미합니다.
훌륭한 소프트웨어 릴리스는 긴밀한 관계를 기반으로 합니다
소프트웨어 개발이 외부와 단절된 상태에서 이루어지는 경우는 거의 없습니다. 실제로 훌륭한 소프트웨어 개발에는 제품 관리 팀에서 운영 팀에 이르기까지 팀 전체가 관여합니다. 예를 들어, 운영 팀은 소프트웨어가 최종 사용자에게 도달하도록 지원하기 때문에 소프트웨어를 프로덕션에 제공하는 데 핵심적인 파트너입니다.
개발 팀은 다음과 같은 기술로 운영 팀에 정보를 제공하고 권한을 부여할 수 있습니다.
- 각 소프트웨어 릴리스에 필요한 사항을 명확하게 하세요. 운영 팀은 릴리스와 관련하여 항상 개발 팀과 동일한 수준의 컨텍스트를 가지고 있지는 않습니다.
- 릴리스에서 해결된 각 이슈에 대해 이슈 추적기와 소스 제어 시스템에 대한 링크를 제공하여, 배포 중에 문제가 발생할 경우 운영 팀이 동일한 수준의 컨텍스트를 가질 수 있도록 하세요.
- 개발 환경에서 스테이징 환경으로 코드를 푸시할 때 이슈가 발생할 때도 있습니다. 프로덕션 푸시 중에 이러한 이슈가 다시 나타날 수 있으므로 이슈를 해결하세요.
- 배포 결함은 발생하기 마련이므로, 문제를 원활하게 해결할 수 있는 명확한 에스컬레이션 경로를 항상 운영 팀에 제공하세요.
운영 팀은 다음과 같은 제안 사항을 통해 상대 팀의 개발을 지원할 수 있습니다.
- 프로덕션 환경에서 문제가 발생하면 근본 원인과 해결 방법을 파악하는 시간을 가지세요. 나중에는 그러한 문제를 방지하거나 더 매끄럽게 처리할 수 있게 됩니다.
- 구성 데이터를 프로덕션에서 스테이징 및 개발 환경으로 다시 마이그레이션하여 구성 편차를 방지하세요.
코드가 개발에서 스테이징, 프로덕션 환경으로 마이그레이션됨에 따라 키 구성과 사용자 데이터는 반대 방향인 프로덕션에서 스테이징, 개발 환경으로 마이그레이션됩니다. 이러한 양방향 관계를 통해 개발 환경이 프로덕션 환경을 밀접하게 모델링할 수 있습니다. 그러면 릴리스 날짜에 버그와 예상치 못한 일이 덜 발생합니다.
훌륭한 소프트웨어 릴리스는 푸시하기 쉽습니다
아무리 강조해도 아무리 강조해도 지나치지 않습니다.
소프트웨어 릴리스를 자동화하는 것은 릴리스 문화를 개선하는 데 가장 좋은 방법입니다. 소프트웨어 릴리스가 현재 자동화되지 않은 경우 먼저 소프트웨어 릴리스를 스테이징 환경으로 자동화하세요. 이 작업이 얼마나 간단한지 모두가 알게 되면, 프로덕션 배포도 자연스레 자동화될 것입니다.
릴리스가 어려운 경우 소프트웨어를 스테이징까지만이라도 자주 릴리스하세요. 개발 팀이 릴리스의 문제점을 느끼도록 하면 릴리스가 더 쉬워지고 자동화되도록 혁신을 유도할 것입니다.
자동화된 테스트와 지속적 통합은 훌륭한 릴리스를 지원하는 핵심 규율입니다. 빌드 시간과 테스트 시간을 최대한 줄이고, 유효성 검사가 쉬운 빌드는 그 주기가 팀을 더 가깝게 따르기 때문에 릴리스하기 더 쉽다는 점을 기억하세요.
훌륭한 소프트웨어 릴리스는 정말 뛰어납니다!
코드를 릴리스 가능한 상태로 유지하는 것은 애자일 개발의 특징입니다.
Atlassian에서는 SaaS 속성을 관리하는 가장 쉬운 방법은 소규모 소프트웨어 릴리스를 자주 하는 것이라고 생각합니다. 다운로드가 가능한 제품의 경우, 개발, 운영, 빌드 엔지니어링 팀 간 긴밀한 협업이 오래 지속됩니다. 이러한 팀은 협업을 통해 소프트웨어 릴리스를 자동화하고 제품에 예정된 변경 사항에 알맞게 자동화를 사전에 조정해야 합니다. Atlassian의 많은 팀에서는 메인의 각 성공적인 빌드를 테스트 환경에 자동으로 배포합니다. 소프트웨어 릴리스를 스테이징으로 승격하거나 고객에게 릴리스해야 할 때, 팀에서는 버튼을 한 번 누르는 것만으로도 자동화 배포를 트리거할 수 있습니다.
소프트웨어 개발자로서 혁신 주기의 하이라이트는 소프트웨어 릴리스여야 합니다. 고객이 우리가 작성한 코드와 상호 작용하고 피드백을 제공하게 됩니다. 릴리스를 업무의 자연스러운 부분으로 만들면 코드를 프로덕션으로 쉽게 진행시키고 "제가 작성한 코드예요!"라고 뿌듯하게 말할 수 있습니다.
DevOps 프로젝트 계획 템플릿으로 무료로 시작하세요
개방형 도구 접근 방식으로 애플리케이션을 개발, 배포 및 관리하세요.
