NetOps가 지속적인 배포를 수용할 때입니다.

지속적인 배포는 반드시 모든 변경을 매번 즉시 수행해야 한다는 것을 의미하지 않습니다. 하지만 어딘가에서 시작해야 합니다.

CI/CD(지속적 통합/지속적 전달)는 개발자의 영역입니다. 이는 전달 속도를 개선하기 위한 포괄적인 모델로, 보다 활동적이고 사용자 관련 맥락에서 이를 보는 데 익숙한 사람들에게는 실제로 "배포 준비 완료"를 의미합니다.

그렇다고 NetOps가 CI/CD를 무시할 수 있다는 것은 아닙니다. 그 반대입니다. 하지만 NetOps가 반드시 1:1 배포 대 제공 비율을 유지해야 한다는 것은 아닙니다. 앱 개발자가 지속적인 배포 기술을 완벽하게 익혔다면 앱이 "배포 준비가 됨"을 의미하는 빈도가 압도적일 수 있으며, 특히 NetOps가 아직 지속적인 배포 기술을 완벽하게 익히지 못했다면 더욱 그렇습니다.  하지만 개발자와 기업 입장에서는 지속적인 배포처럼 느껴질 수 있는 더 빈번한 배포를 수용할 여지가 있습니다. 

비결은 앱의 '사소한 변경'과 '중요한 변경'의 차이에 있습니다.

2016년 가을 NetDevOps 설문 조사에 따르면 사소한 변경 사항이 우리가 흔히 생각하는 것보다 훨씬 더 빈번하게 프로덕션에 반영되고 있는 것으로 나타났습니다. 응답자의 약 51%가 하루에 두 번 이상 사소한 변경 사항을 프로덕션에 적용하고 있습니다. 3명 중 1명 이상은 한 달에 1~5회 정도의 주요 변화를 추진했으며, 3분의 1은 한 달에 한 번도 주요 변화를 추진하지 않는다고 고백했습니다.

불행히도 "중요한" 변화와 "사소한" 변화의 정의는 정량화되어 있지 않지만, 평소처럼 이러한 상대적인 설명자는 종종 산업이나 조직에만 고유한 것이 아니라 각 애플리케이션에도 고유한 경우가 많습니다. 그래도 상당수(절반이 조금 넘음)가 정기적으로 프로덕션에 주요 변경 사항을 배포하고 있는 것 같습니다.

즉, 큰 그림에서 보면 우리는 지속적인 배포 방향으로 작은 발걸음을 내딛고 있다는 뜻입니다. 문제는, 새롭고 멋진 애플리케이션을 배포하는 것이 기존 애플리케이션에 업데이트를 배포하는 것과 다르다는 것입니다. 새로운 네트워크나 앱 서비스를 추가하더라도 완전히 새로운 애플리케이션을 배포하는 것보다 "중단 가능성" 측면에서 여전히 상당히 다릅니다.

그러니 지금으로서는 새롭고 멋진 앱에는 더 많은 조정과 계획이 필요할 겁니다. 여전히 대부분의 프로덕션 앱이 지속적인 배포의 잠재적 대상이 될 가능성이 있습니다. 우리가 장려할 수 있는 것 중 하나는 프로덕션 환경에 미치는 영향과 관련하여 "사소한" 변경과 "중요한" 변경에 대한 맥락을 제공하는 것입니다.

사소한 변경 사항은 앱 내부적으로 영향을 미치는 사항으로만 제한될 수 있습니다. 예를 들어 논리의 변화. 여기에는 앱 스택(웹 서버, 앱 서버 등)에 대한 패치나 업그레이드는 물론, 이를 지원하는 앱 인프라에 대한 패치나 업그레이드도 포함될 수 있습니다. 기본적으로 사소한 변경은 앱에만 영향을 미칩니다. 일반적인 사용에서 앱을 실제로 제공하고 보호하는 네트워크나 앱 서비스에 대한 변경은 필요하지 않습니다.

그러면 주요 변경 사항은 앱을 지원하는 네트워크나 앱 서비스에 영향을 미치는 변경 사항입니다. 주요 변경 사항에는 전달 정책(압축 켜기, 맞죠?)을 조정하거나 URL 필터링이나 요청 검사와 같이 최근에 발견된 취약성을 악용하지 못하도록 하는 새로운 서비스를 삽입해야 할 수 있습니다. 이러한 변화는 다른 애플리케이션에 영향을 미칠 수도 있고 그렇지 않을 수도 있는, 더 광범위한 프로덕션 시스템에 영향을 미친다는 점에서 중요한 변화입니다.

외부 서비스에 미치는 영향을 고려하여 보다 미묘한 채점 시스템을 구축할 수도 있습니다. 새로운 서비스는 기존 서비스를 조정하는 것보다 더 파괴적일 가능성이 높습니다. 새로운 정책은 약간의 업데이트가 있는 기존 정책보다 구현에 더 많은 주의가 필요합니다.

사용할 "시스템"에 동의하면 필요에 따라 사소한 변경을 허용하는 데 동의하기가 훨씬 쉬워집니다. 기본적으로 앱 배포가 프로덕션으로 흐르도록 하여 지속적인 배포로 전환하는 것입니다 . 다만 문제가 발생하더라도 잠재적인 영향이 최소화되어야 합니다 . 사소한 변화, 사소한 위험. 적어도 그게 가정이에요.

이를 통해 사소한 기술적 변화라도 중대한 비즈니스 변화로 이어질 수 있고, 그 변화가 더 빨리 사용자에게 전달될 수 있습니다. 이런 일은 대규모의 전통적인 조직에서 종종 일어나는 일이기 때문입니다. 일정 충돌과 프로젝트 우선순위나 정치에 따른 변경 관리 위원회의 결정으로 인해 사용자 인터페이스를 약간만 변경하더라도 몇 주 이상 지연될 수 있습니다. 작은 변화가 더 나은 사용자 경험을 의미하여 전환율이나 고객 유지율을 높이는 데 도움이 될 수도 있습니다. 만약 그 작은 변경 사항 이 앱에만 영향을 미치는, 즉 "사소한" 변경이라면, IT 정책이 실제로 그것을 지연시키는 이유가 될까요?

지속적인 배포는 기술적으로 자동화된 푸시를 프로덕션에 적용하는 것뿐만 아니라 애플리케이션과 업데이트가 프로덕션에 적용되는 시기를 결정하는 프로세스를 지연시키는 기존 구조를 해체하는 것입니다(이것이 문화입니다).

앱 외부의 시스템에 영향을 미칠 가능성이 있는 업데이트와 그렇지 않은 업데이트인 "사소한" 업데이트와 "중요한" 업데이트를 구별하기 위한 공통 기준을 확립함으로써 조직은 추가적인 위험이나 프로덕션 불안정 없이 일부 변경 사항에 대한 지속적인 배포를 활성화할 수 있습니다. 그리고 그것은 사업에 긍정적인 영향을 미쳐 모두가 이득을 얻는다는 것을 의미할 수도 있습니다.