소프트웨어 배포란?

완료됨

Wikipedia에 따르면 ‘소프트웨어 배포’는 소프트웨어 시스템을 사용할 수 있도록 하는 모든 활동으로 구성됩니다. 일반 배포 프로세스는 상호 연결된 여러 활동으로 구성되며 이러한 작업 간에 전환이 가능합니다. 모든 소프트웨어 시스템은 고유합니다. 따라서 “배포”는 특정 요구 사항 또는 특성에 따라 사용자 지정해야 하는 일반 프로세스로 해석됩니다.

“배포”와 “설치”라는 용어를 서로 바꿔서 사용하는 경우도 있지만, 소프트웨어 설치는 소프트웨어 배포 프로세스의 한 부분일 뿐입니다. 배포에는 훨씬 더 많은 의미가 포함됩니다. 배포 작업에는 다음이 포함될 수 있습니다.

  • 서버를 ‘래킹 및 스태킹’합니다.
  • 업데이트된 소프트웨어 조각을 해당 서버에 배포합니다.
  • 스크립트 및 인프라와 같은 항목을 코드로 사용합니다.
  • USB 드라이브를 들고 사무실을 돌아다니며 컴퓨터에 소프트웨어를 수동으로 설치하는 경우도 해당됩니다.

소프트웨어를 수동으로 배포하는 것은 노동 집약적이며 확장성이 좋지 않습니다. 자동화는 조직 전체에 새 소프트웨어를 배포하거나 기존 소프트웨어를 업데이트하는 작업을 보다 비용 효율적이고 쉽게 만들어 줍니다.

이 학습 경로의 일부로 중점을 두는 부분은 안정성을 위한 최상의 소프트웨어 배포 방법입니다. 이 모듈에서는 소프트웨어 배포뿐만 아니라 클라우드 인프라 배포도 다룹니다. 서비스 또는 솔루션 배포가 소프트웨어, 클라우드 인프라, 구성 및 시스템을 안정적으로 사용할 수 있도록 하는 데 필요한 모든 항목의 배포를 의미할 수 있습니다.

시나리오: 대규모 배포

에픽(epic)이라는 단어는 '웅장하고 기념비적이며 방대한'이라는 뜻이지만, 이 논의의 맥락에서는 좋은 의미는 아닙니다. “대규모”라는 용어는 Jez humble의 저서 Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation에서 처음 사용되었습니다. 대량으로 진행되는 것을 나타내기 때문입니다. 일반적으로 발생하는 방식의 예는 다음과 같습니다.

  • 조직에서 영업 관련 애플리케이션을 개발합니다. 이 애플리케이션은 매년 정확히 두 번 업데이트됩니다.
  • 이러한 업데이트 중에는 모든 새로운 기능, 버그 수정(크고 작은) 및 종속성 업데이트가 배포됩니다.
  • 해당 연도의 첫 번째 배포는 노동절에 수행되고 두 번째 배포는 추수감사절 다음 주말에 수행됩니다.
  • 각 업데이트는 “모두 실습 데크” 상태입니다. 애플리케이션 팀, 지원 팀, 인프라 팀, 관리 팀 모두가 배포에 참여합니다.
  • 배포가 진행되는 동안 서비스가 일시적으로 오프라인 상태로 전환됩니다.
  • 기록에는 배포로 인해 항상 문제, 주문형 엔지니어링, 문제 해결 및 구성 관리 변경이 따른다고 되어 있습니다.
  • 잘 수행되는 경우가 많지 않으며, 배포가 완료되면 일반적으로 답답해 집니다.

이는 좋은 배포 상태가 아닙니다. 대규모 배포 방법은 많은 문제를 나타내는 치열한 수동 작업입니다.

  • 복잡합니다.
  • 스트레스가 많습니다.
  • 위험합니다.
  • 속도가 느립니다.
  • 모든 단계가 복잡하기 때문에 재현할 수 없습니다.
  • 배포를 완료하려면 여러 개인 전문가가 필요하기도 합니다.

이 프로세스는 시간이 오래 걸리고 몹시 힘들기 때문에 사용자 생산성 중단을 최소화하는 시간에 예약해야 합니다. 즉, 주말 및 휴일 등의 배포 팀에 불편을 끼칠 수 있는 시간을 의미합니다.

팀 멤버가 대량의 작업을 시간 프레임 내에 완료해야 한다는 압박감을 느껴 구성에 실수가 발생할 수 있습니다. 또한 배포 간에 시간이 오래 걸리면 작업 방식을 정확히 잊어버릴 수 있습니다.

배포 딜레마

소프트웨어 배포는 복잡한 작업이며, 여러 주요 변경 내용, 수정 사항 및 기능 추가를 ‘저장’하여 모두 한 번에 배포하는 경우 복잡성이 증가하여 문제가 발생할 가능성이 높아집니다. 또한 문제가 발생했을 때 이러한 복잡성으로 인해 문제가 발생한 원인을 정확하게 추적하기가 더 어려워집니다.

최종 사용자는 대규모(epic) 배포의 복잡성으로 인해 발생하는 버그는 말할 것도 없고, 새로운 기능과 변경 사항을 한꺼번에 익혀야 하기 때문에 복잡성이 문제를 야기할 수도 있습니다.

더 나은 방법이 있어야 하며, 실제로 있습니다. 좋은 소식은 기존의 대규모 배포 전략이 유일한 옵션이 아니라는 것입니다. 다음 단원에서는 이 프로세스를 진행하는 더 나은 방법을 알아보겠습니다.