지속적인 업데이트와 지속적인 배포 비교

이 두 가지 자동화 방식을 통해 고객에게 고품질 코드를 빠르게 제공할 수 있습니다.

지속적인 업데이트와 지속적인 배포란?

연속 통합과 함께 지속적인 업데이트와 지속적인 배포는 소프트웨어 제공 단계를 자동화하는 방식입니다. 이 방식을 통해 개발 팀은 속도, 정확성 및 생산성을 높여 고객에게 새로운 기능, 향상된 기능 및 수정 사항을 릴리스할 수 있습니다.

지속적인 업데이트와 지속적인 배포는 공통점이 많습니다. 이 방식의 차이점을 이해하고 구현할 방식을 확인하려면 자동화할 수 있는 소프트웨어 제공 단계를 식별해야 합니다.

소프트웨어 제공 프로세스 자동화

소비자는 점차 제품의 맞춤화 및 보안을 요구합니다. 이 요구 사항을 충족하고 소프트웨어를 더 빠르고 안정적으로 제공하려면 개발 팀에서 DevOps 문화를 채택하면 됩니다.

DevOps 문화는 고립된 분야를 없애고 인력, 프로세스 및 기술을 통합하여 협업 및 조정을 개선합니다. 따라서 가능한 한 빨리 코드 변경 내용이 프로덕션 환경에 도달하고 새 값이 고객에게 도달합니다.

개발, IT 운영, 품질 엔지니어링 및 보안 팀이 모두 DevOps에서 긴밀하게 협업하지만, 소프트웨어 제공 프로세스는 여전히 복잡합니다. DevOps에서는 소프트웨어 제공이 계획, 개발, 제공, 배포 및 운영의 4단계로 구성됩니다.

DevOps의 소프트웨어 제공

자동화를 사용하지 않는 경우 개발 팀은 소프트웨어를 수동으로 빌드, 테스트 및 배포해야 합니다(다음과 같은 과정이 포함됨).

  • 코드를 체크 인하고 테스트하고 유효성을 검사합니다.
  • 코드 변경 내용을 주 분기에 병합합니다.
  • 코드를 라이브 상태로 전환하기 위해 준비합니다.
  • 배포 가능한 아티팩트를 만듭니다.
  • 코드를 프로덕션 환경으로 푸시합니다.

자동화할 단계

지속적인 통합, 지속적인 업데이트 및 지속적인 배포는 모두 개발 및 제공 단계의 측면을 자동화하는 방식입니다. 또한 각 방식은 지속적인 통합부터 시작하여 자동화를 한 단계 더 발전시킵니다.

지속적인 업데이트와 지속적인 배포의 차이점

연속 통합

지속적인 업데이트 및 지속적인 배포를 설명하기 위해 지속적인 통합으로 시작합니다. 지속적인 통합에서 개발 단계(코드 작성 및 테스트)는 완전히 자동화됩니다. 코드를 커밋할 때마다 변경 내용의 유효성이 검사되고 변경 내용이 마스터 분기에 병합되며 코드는 빌드 아티팩트에 패키지됩니다.

연속 배달

지속적인 업데이트는 다음 단계인 제공을 자동화합니다. 지속적인 업데이트에서는 언제든지 새 빌드 아티팩트를 사용할 수 있게 되면 아티팩트가 자동으로 원하는 환경에 배치되고 배포됩니다.

CI/CD(연속 통합 및 지속적인 업데이트)

팀에서 CI/CD(지속적인 통합 및 지속적인 업데이트)를 모두 구현하면 개발 및 제공 단계가 자동화됩니다. 코드는 언제든지 프로덕션 환경에서 사용할 수 있는 상태로 유지됩니다. 모든 팀에서는 개발에서 배포로의 전환을 수동으로 트리거하여 자동 배포에 대해 자동화된 빌드 아티팩트를 사용할 수 있도록 해야 합니다. 이 작업은 단추를 누르는 것처럼 간단할 수 있습니다.

연속 배포

지속적인 배포를 사용하면 코드 커밋부터 프로덕션 환경까지 전체 프로세스가 자동화됩니다. 개발 단계와 제공 단계 간의 트리거가 자동이므로 코드 변경 내용이 유효성 검사를 받고 모든 테스트를 통과하면 라이브로 푸시됩니다. 즉, 고객은 개선 사항이 사용 가능해지는 즉시 개선 사항을 받게 됩니다.

지속적인 업데이트와 지속적인 배포 비교: 어떤 것을 선택해야 할까요?

지속적인 업데이트 또는 지속적인 개발 중 무엇을 채택하든 관계없이 지원에 필요한 도구를 찾을 수 있습니다.

이 방식 중 구현할 방식을 고려하기 전에 조직에 이 방식을 지원할 수 있는 DevOps 문화가 마련되어 있는지 확인합니다. 다음으로, DevOps 팀은 전체 소프트웨어 제공 프로세스를 자동화하기 위해 노력하므로 “어떤 것이 더 나은가?”라는 질문이 아니라, “지속적인 통합과 지속적인 업데이트 사이에 수동 트리거가 필요한가?”라고 질문합니다.

대답을 구해가면서 다음 질문을 사용하면 도움이 됩니다.

  • 관련자의 승인 없이 배포할 수 있는가?
  • 시스템 및 제한 요구 사항에서 엔드투엔드 자동화를 허용하는가?
  • 한 번에 조금씩 프로덕션 환경 변경 내용에 고객을 노출할 수 있는가?
  • 조직에서 프로덕션 환경의 오류에 빠르게 대응하는가?

모두 ‘예’로 대답한 경우 코드 커밋부터 프로덕션 환경까지 지속적인 배포를 실행하고 소프트웨어 제공을 완전히 자동화하는 것을 고려할 수 있습니다.

‘아니요’로 대답한 항목이 있는 경우 CI/CD(지속적인 통합 및 지속적인 업데이트)로 시작해야 할 수 있습니다. 배포에서 항상 하나의 수동 승인인, 프로덕션 환경에서 사용할 수 있는 코드의 생성을 자동화합니다. 시간을 두고 점차 지속적인 배포 및 소프트웨어 제공 프로세스의 완전 자동화를 위해 노력할 수 있습니다.

어느 방식이든 다음과 같은 각 방식의 공통 이점을 얻을 수 있습니다.

  • 변경 내용이 자동으로 빌드되고 유효성이 검사된 후 테스트됩니다.
  • 코드는 항상 배포 가능하며, 더 이상 릴리스 날의 걱정이 없습니다.
  • 릴리스는 관련자 및 고객 피드백을 더 빠르게 받습니다.
  • 개발자는 수동 및 관리 작업이 소수여서 생산성을 높일 수 있습니다.
  • 변경 내용이 작으며 자주 발생하므로 오류는 드물게 발생하며 불안정성이 최소화됩니다.

지속적인 통합, 지속적인 업데이트 및 지속적인 배포용 도구

DevOps 팀은 도구 체인(일련의 연결된 소프트웨어 개발 프로그램)을 사용하여 소프트웨어 제공을 자동화합니다. 사용할 도구는 선택하는 자동화 방식 및 해당 방식에서 자동화하는 단계에 따라 달라집니다. 다음은 몇 가지 예입니다.

Azure에서 DevOps 수행 시작

지속적인 업데이트 및 지속적인 개발 도구와 클라우드에서 다른 DevOps 방식을 활용할 수 있는 도구를 살펴보세요.