지속적 제공이란?

과거에는 소프트웨어가 최종 사용자에게 출시되기 전에 엄청난 개발, 테스트, 수정 과정을 통과해야 했습니다. 전체 제품이 테스트를 통과하여 배포되기 전에 미리 개발되는 이 Waterfall 방법론은 너무 긴 시간이 소요되었으며 배포 주기가 느려지고 사용자 경험이 덜 긍정적이었습니다.

DevOps의 핵심 구성 요소이자 CI/CD라는 더 큰 맥락 안에서 유효한 지속적 제공은 Agile 소프트웨어 혁명의 일부로 등장했습니다. 지속적 제공은 완벽한 패키지를 한꺼번에 만드는 대신, 테스트 같은 반복 작업에 고급 자동화 솔루션을 사용하는 동시에 프로덕션에 들어갈 수 있는 코드 빌드의 모든 측면을 통합하므로 개발자가 사소한 소프트웨어 변경을 좀 더 일정한 속도로 제공할 수 있습니다. 경우에 따라 코드가 프로덕션으로 바로 전달될 수 있는데, 이를 지속적 배포라고도 합니다.

기업과 소프트웨어 벤더에 제공하는 여러 가지 주요 이점은 다음과 같습니다.

개발자가 대규모 배포를 출시하면 잘못될 수 있는 요소가 많습니다. 지속적 제공은 사소한 변경에 초점을 맞춰 배포의 위험을 제한합니다. 사소한 변경은 조사와 문제 해결이 더 쉽고, 예상대로 작동하지 않을 경우 수정하는 데 드는 시간이 짧기 때문입니다.

지속적 제공을 도입하면 개발자가 작업을 완료할 때까지 기다릴 필요 없이 애플리케이션 및 프로젝트 소유자가 소프트웨어 제공 주기를 추적하고 언제 어떻게 프로덕션 또는 테스트 환경에 배포를 계속할지 결정하여 진행 상황을 쉽게 차트로 만들 수 있습니다. 경우에 따라, 가치 흐름 관리 솔루션 내에서 지속적 제공 수명주기 전반에 걸쳐 수집한 정보를 활용하여 여러 팀의 상대적 기능을 이해하고 병목 현상을 파악하여 없애는 것이 바람직할 수 있습니다.

미리 확립된 개발 단계를 따라 소프트웨어 배포가 이루어지는 경우 각 단계마다 상당한 시간이 소요될 수 있습니다. 지속적 제공을 선택하는 팀은 테스트 및 수정 작업을 다른 일상 프로세스에 구축해야 하는데 이때 빌드, 프로비저닝 등을 자동화에 의지하므로 부담을 덜게 됩니다. 따라서 개발 단계가 단축되고 중복 작업이 훨씬 줄어들 뿐만 아니라 처리 시간도 앞당길 수 있습니다. 사실, 지속적 제공의 특징은 언제든 릴리스할 수 있는 소프트웨어를 생산한다는 것입니다. 즉, 기존 소프트웨어 개발의 긴 제공 시간에 비해 눈에 띄게 개선된 효과를 얻을 수 있습니다.

개발자가 빌드에 엄청난 시간을 투자했지만 릴리스의 효과가 없거나 제대로 받아들여지지 않은 경우, 그동안의 노력이 거의 수포로 돌아간 채 다시 원점에서 시작할 수밖에 없었습니다. 더 짧은 주기로 자주 릴리스하면 테스트 및 기타 문제가 더 빨리 드러나고, 애플리케이션 사용자가 조기에 자주 피드백을 제공할 수 있으므로 개발자가 필요에 따라 궤도를 수정할 수 있습니다.

제공 수명주기 전반에 걸쳐 신뢰할 수 있는 피드백이 제공되면 개발자는 제품을 개선하고 간소화하여 기능과 아이디어를 테스트하고, 불필요하거나 비효율적이거나 부정적인 사용자 경험을 유발하는 요인을 제거할 수 있습니다.

지속적 제공은 과거 소프트웨어 개발의 난제였던 수많은 고정 비용을 없애기 위해 자동화에 의존합니다. 즉 개발 초기뿐만 아니라 수명주기 전반에 걸친 비용 투자가 적게 들고, 투자 비용에 대한 수익이 높습니다.

개발 마라톤과 다가오는 프로젝트 기한은 개발 팀을 지치게 합니다. 이에 비해 소규모 수정과 릴리스는 다른 업무와 병행하면서 더 쉽게 관리할 수 있습니다. 지속적 제공은 스트레스를 덜 받는 작업 환경을 조성하고 번아웃을 방지할 뿐만 아니라, 개발자가 사용자와 더욱 직접적으로 상호작용하면서 자신의 노력이 고객에게 얼마나 유익한지 정확히 알 수 있게 해줍니다.

표면적으로 지속적 제공은 지속적 배포와 매우 비슷해 보입니다. 물론, 둘 다 Agile 방식의 소프트웨어 개발 방법에 속하지만, 두 버전 사이의 미묘한 차이를 알면 좋습니다.

앞서 언급했듯이 지속적 제공은 소프트웨어 개발과 관련된 많은 프로세스를 자동화하고, 팀이 제품을 점진적으로 계속 변경할 수 있는 자율성을 보장합니다. 그러나 지속적 제공의 마지막 단계인 프로덕션 배포에 대한 승인은 자동화되지 않습니다. 테스트 환경에 푸시된 변경 사항은 일반적으로 전체 배포가 예정된 릴리스의 일부로 수동 검토와 승인을 받아야 합니다.

지속적 배포는 미리 정의된 일정에 따라 또는 지속적 제공 프로세스에서 코드가 전달되는 즉시 업데이트를 자동으로 배포하여 자동화를 더욱 강화합니다. 코드에 배포 기간이 필요하지 않은 경우 믿을 만한 방식으로 변경 거버넌스(사용된 경우)를 자동화함으로써 개발자가 프로덕션에 직접 액세스할 수 있으며 업데이트를 직접 출시할 필요 없이 정기적으로 업데이트가 배포되도록 보장할 수 있습니다. 그러면 일정 기간 동안 기업이 더 자주 배포할 수 있고, 심지어 주요 릴리스의 번거로움을 상당히 덜어낼 수 있습니다. 대부분의 조직에서 지속적인 배포가 좌절되는 이유는 산업 규정 등으로 인해 강력한 거버넌스가 필요하기 때문입니다. 이러한 종류의 조직에서 지속적 배포를 구현할 가능성은 공식 변경 관리 프로세스에서와 같이 수동 승인이었던 것을 효과적으로 자동화하는 능력에 좌우됩니다.

지속적 제공의 전체 개념은 파악하기 쉽습니다. 시간 집약적인 개발 프로세스를 자동화에 의한 소규모 작업과 릴리스로 나누는 것입니다. 그러나 아이디어를 이해하는 것과 방법론 구현 방법을 아는 것은 별개의 문제입니다. 지속적 소프트웨어 제공으로 전환하기 위해 필수적인 전제 조건은 다음과 같습니다.

개발 팀의 사고 방식과 프로세스에는 앞서 언급한 Waterfall 방식의 소프트웨어 개발이 ​​깊이 자리잡고 있을 수도 있습니다. 따라서 DevOps와 Agile 개발 문화로 전환하기 위해서는 광범위한 계획과 철저한 교육이 필요합니다. 개발 팀이 전력을 다하지 않으면 지속적 제공은 성공할 수 없습니다.

DevOps로 문화적 전환이 이루어지려면 소프트웨어 개발의 한계를 넘어서는 영향이 있어야 합니다. 빠른 피드백 루프와 효과적인 의사결정에는 리더십과의 확실한 협업과 조율이 필요하며, 그래야 모든 사람이 최적의 프로세스를 철저히 인식하고 전력을 다할 수 있습니다.

최종 제품이 보안 또는 규정 준수 요구에 부합하지 않으면 빠른 처리 시간과 원활한 소프트웨어 릴리스도 조직에 큰 도움이 되지 않습니다. 다행히 지속적 제공 전반에 걸쳐 사용되는 동일한 여러 자동화 도구 방식은 배포와 관련된 보안 위험을 최소화하는 데 도움이 될 수 있습니다. 전문 보안 팀이 정한 정책이 적용된, 자동화된 코드 스캔 도구가 파이프라인의 일부가 됩니다. 자동화된 변경 관리를 사용 중인 경우 이러한 스캔의 성공적인 완료는 변경 요청을 자동으로 생성하고 승인하는 데 사용되는 정보의 일부가 됩니다.