Production Ready는 User Ready가 아닙니다.

지속적인 배포는 조직이 DevOps를 도입하는 궁극적인 목표입니다. 이는 최종 목표가 아니며, 지속적인 배포가 필요하기 때문입니다.

DevOps 분야에서는 하루에 수없이 많은 프로덕션에 바로 사용할 수 있는 소프트웨어를 제공하는 능력에 대한 많은 논의가 이루어지고 있습니다.

좋죠.

제가 이에 대해 그다지 흥분하지 않는 이유는 대부분의 기업 조직에서(DevOps를 도입한 조직도 포함) 제공은 애플리케이션 수명 주기의 '시장 출시' 단계에서 단지 첫 단계에 불과하기 때문입니다. 최종 빌드 및 릴리스 알림이 전달된 후 사용자에게 "준비"된 애플리케이션은 거의 없습니다. 사용자에게 적절하게 전달되기 위해서는 다양한 절차와 정책이 필요한데, 이를 위해서는 프로덕션에 배포해야 합니다.

지속적인 배포는 조직이 DevOps를 도입하는 궁극적인 목표입니다(되어야 하고, 될 수도 있고, 될 것입니다). 그렇지 않더라도 더 큰 문제는 단순히 프로덕션에 전달한다고 해서 애플리케이션이 구성 요소에 "전달"되는 것은 아니라는 것입니다. 이를 위해서는 기업과 소비자 모두에게 최적의 애플리케이션 경험을 제공하기 위해 애플리케이션을 확장, 보안 및 가속화하는 데 필요한 모든 서비스와 함께 프로덕션에 배포해야 합니다.

이는 확장성과 가용성을 보장하기 위해 부하 분산을 의미할 수 있습니다. 이는 거의 확실히 보안을 의미합니다. 최소한 방화벽에서 보안이 강화되고, 앱 보안이 강화되며, 아마도 그 이상이 될 수도 있습니다. 이는 접근 권한과 신원을 의미할 수도 있습니다. 소비자 대상 앱에는 적합하지 않을 수 있지만 기업 대상 앱은 원활하고 간편한 액세스를 보장하기 위해 SSO 또는 연합 정책에 포함되어야 할 수도 있습니다. 성능 측면에서도 속도가 필요할 수 있습니다.

앱이 사용자에게 "제공"되기 전에 이러한 모든 작업이 완료되어야 합니다. 그리고 "제작"은 그것을 알고 있습니다. 2017년 애플리케이션 제공 현황 조사에서 "1~10개의 서비스를 배포했다"고 답한 응답자는 32%였고, 대부분은 "5개 이상을 배포했다"고 답했으며, 63%가 현재 6~10개를 배포했다고 답했습니다.

"지속적인 배포" 문제와 상관없이 이러한 서비스는 앱이 단순히 "생산을 위한 준비"가 아닌 "사용자를 위한 준비"가 되도록 하는 데 중요합니다.

생산 단계에 수십 번 제품을 공급하는 것도 좋지만, 시장에 더 자주 공급하는 것이 진정한 목표입니다. DevOps가 앱과 직접적인 인프라를 처리하기 위해 프로덕션에 들어간다 하더라도(어서 오세요! 정말 물이 좋습니다!) 앱이 실제로 "배달"된 것으로 간주되기 전에 프로비저닝, 구성 및 테스트해야 하는 업스트림 서비스가 여전히 있을 것입니다.

앱을 더 자주 프로덕션에 출시하는 것은 실제로 배포 일정에 영향을 미치지 않습니다. 오픈소스 프로젝트에 "안정적인" 브랜치와 "야간 빌드" 옵션이 있는 데는 이유가 있습니다. 물론 최신 최고의 것을 얻을 수도 있지만 사용자로서 저는 "안정적인" 옵션을 선호합니다. 앱이 중단되거나 무작위로 충돌하는 것은 긍정적인 애플리케이션 경험에 전혀 도움이 되지 않기 때문입니다.

배포 일정은 비즈니스가 주도하고 IT가 구현해야 합니다. 즉, IT(4가지 운영 부문 모두)를 참여시켜 가능한 한 많은 프로세스를 자동화해야 합니다. 앱이 프로덕션에서 이를 둘러싼 서비스에서 보안 및 속도가 보장되지 않아 사용자가 사용할 수 없습니다.