Java 개발자를 위한 DevOps 도구

10장. 지속적 배포패턴 및 안티패턴

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

스티븐 친

바룩 사도구르스키

다른 사람의 실수로부터 배우세요. 혼자서 모든 실수를 저지르며 살 수는 없습니다.

엘리너 루즈벨트

이 장에서는 조직에서 DevOps 모범 사례를 성공적으로 구현하는 데 필요한 지속적인 배포를 위한 패턴 을 제공합니다. 배포 프로세스를 개선하는 데 필요한 변화에 대해 조직 내 다른 사람들을 설득하려면 지속적인 업데이트에 대한 근거를 이해하는 것이 중요합니다.

또한 지속적인 업데이트 모범 사례를 채택하지 않은 기업들의 실패 사례도 많이 소개합니다. 다른 사람들의 실패에서 배우는 것은 좋은 일이며, 첨단 기술 업계에는 하지 말아야 할 일과 모범 사례를 무시했을 때의 결과에 대한 최근 사례가 많이 존재합니다.

이 장을 마치면 소프트웨어 업계의 상위 26%에 속하는 DevOps '엘리트 수행자'에 합류하기 위해 지금 바로 사용할 수 있는 7가지 지속적인 업데이트 모범 사례에 대한 지식으로 무장하게 됩니다.

모두에게 지속적인 업데이트가 필요한 이유

지속적인 업데이트는 더 이상 소프트웨어 개발의 선택 사항 이 아니라 모든 주요 프로젝트에서 채택해야 하는 모범 사례입니다. 지속적인 업데이트 제공 계획은 프로젝트의 기능적 요구 사항만큼이나 중요하며 안정적으로 실행하기 위해서는 높은 수준의 자동화가 필요합니다.

예전에는 소프트웨어가 훨씬 더 낮은 주기로 제공되었고 중요한 업데이트만 제공되었습니다. 또한 업데이트 설치는 스크립트 조정, 데이터 마이그레이션 및 상당한 다운타임이 수반되는 오류가 발생하기 쉬운 수동 프로세스인 경우가 많았습니다.

지난 10년 동안 모든 것이 바뀌었습니다. 이제 최종 사용자는 소비자 디바이스와 지속적으로 업데이트되는 애플리케이션에 대한 경험을 바탕으로 새로운 기능 이 지속적으로 추가되기를 기대합니다. 또한 보안 연구자들이 패치하지 않으면 시스템을 손상시키는 데 사용할 수 있는 새로운 취약점을 지속적으로 발견하기 때문에 중요한 업데이트를 연기( )하는 것과 관련된 비즈니스 위험도 상당합니다. 마지막으로 전체 인프라 스택이 보안 개선을 위해 지속적으로 업데이트되고 애플리케이션도 업데이트해야 하는 경우가 많아지면서 지속적인 업데이트 소프트웨어 는 클라우드 시대에 비즈니스 기대가 되었습니다.

모든 소프트웨어 프로젝트가 지속적인 업데이트 전략을 신속하게 채택한 것은 아니며, 특히 기술 도입 주기가 긴 산업에서는 더욱 그렇습니다. 그러나 일반적인 하드웨어 아키텍처와 오픈 소스 기술이 널리 사용된다는 것은 이러한 프로젝트가 중요한 취약점에 노출될 위험이 동일하다는 것을 의미합니다. 취약점이 노출되면 복구가 어렵거나 불가능한 치명적인 장애로 이어질 수 있습니다. 다른 소프트웨어와 마찬가지로 오픈 소스 프로젝트에는 버그와 보안 취약점이 있으며, 독점 프로젝트보다 빠르게 수정 및 패치되지만 조직이 업데이트를 하지 않으면 패치해도 무슨 소용이 있을까요? ...