지속적인 통합은 지속적인 전달 / 배포와 어떤 관련이 있습니까?


20

의 현재 내용에서 인용 한 내용은 다음과 같습니다 .

... 통합 문제를 방지하거나 최소화하기 위해 개발자의 작업 코드 사본을 공유 코드베이스에 자주 병합하는 프로세스입니다.

알았어 그러나 또한이 , 나는 그의 지속적 조금 분실 :

  • 어떻게 지속적인 통합 과 관련된 지속적인 전달 및 / 또는 지속적인 전개 를 통해 라인 (들)을 따라 그 곳을 가정, integration당신은 결국 delivering모든 것 대상 환경에서 deployed.
  • 사이의 차이가 무엇 지속적으로 전달 하고 지속적인 배치는 ?

예전에는 DevOps가 DevOps라고 불리기 전에 다음과 같은 새로운 DevOps 용어를 이해하는 데 도움이되는 용어를 사용했습니다.

  • 선택적으로 일부 유형의 재생성 프로세스 (컴파일, 바인드 등)와 결합하여 실행 가능한 것과 같은 모든 관련 컴포넌트를 함께 패키지하기 위해 사전 제작 대상으로 승격 (또는 강등 )합니다. 그것이 지속적인 통합 과 비슷하거나 비슷해야 하는가?
  • FTP와 같은 것을 사용하여 일부 대상 환경에 배포 하지만 (표준 사본이 간격을 메울 수없는 경우) 대상에서이를 활성화하지 마십시오. 그것이 지속적인 전달 과 비슷하거나 비슷해야 하는가?
  • 바인드, 중지 / 시작 작업 등과 같은 일부 대상 환경에 설치 (또는 활성화 )합니다. 이것이 지속적인 배포 와 비슷하거나 근접해야 하는가?

태그 마크가 너무 많으면 읽기 어렵습니다. 그것은 질문에 더 많은 맥락을 제시하지 않기 때문에 나는 독서를 쉽게하기 위해 _markdown_
Ords

1
나는 편집이 고통이라는 것을 의미한다 :) 답변에 대한 힌트 blog.crisp.se/wp-content/uploads/2013/02/…
Tensibai


답변:


23

지속적인 배포 및 지속적인 배포는 프로세스에 'Deployment to Production'단계를 추가하여 한 단계 더 지속적인 통합을 수행합니다. 지속적인 배달과 배포의 차이점은 배달을 위해이 단계는 수동으로 수행되며 배포는 자동으로 수행된다는 것입니다.

지속적인 통합, 지속적인 제공 및 지속적인 배포의 차이점

지속적인 통합, 지속적인 배포 및 지속적인 배포의 차이점 codeproject.com 에서 복사 한 사진

지속적인 전달을 수행하든 지속적으로 전개하든 구현 선택은 매우 중요합니다. 연속 배포를 수행하면 승인 테스트를 통과 한 후 코드 변경 사항이 자동으로 배포됩니다. 이것은 제품에 바람직하거나 바람직하지 않을 수 있습니다. 지속적인 배포를 통해 사람들은 특정 코드 변경이 배포되었는지 아닌지 (정확하게 배포되는 위치)를 선택할 수 있습니다.

지속적인 제공과 배포의 차이는 작고 많은 사람들이 정확한 차이를 인식하지 못하기 때문에 두 용어가 서로 바꿔서 사용되기도합니다.


좋은! 그러나 ... 문제 (내 질문)에 대한 해결책 (답변)은 문제를 바꿉니다 ... 더 읽기 ...
Pierre.Vriens

4

지속적인 배포와 지속적인 배포 (CD)는 거의 같은 것입니다 *. 변경 사항이 '행진'(테스트 / 검증)으로 간주 될 때마다 즉시 해제해야합니다. 작업이 완료되면 하루에 여러 번이 작업을 수행 할 수 있습니다.

연속 통합 (CI)은 기능 분기가 기본 '마스터'분기에서 너무 멀리 떨어져 있지 않도록하기 위해 코드를 자주 병합하는 것만 참조하며, 통합 관점-즉, 변경하면서 기능을 중단 했습니까?

CI가 서로 관련되는 한, CI는 코드를 빠르게 확인하여 CD (빠른 릴리스)가 가능하도록 도와줍니다. 여전히 CI없이 CD를 얻을 수 있지만 그 반대의 경우에도 코드를보다 쉽게 ​​통합하고 문제를 더 빨리 찾을 수 있기 때문에 종종 문제를 더 빨리 해결할 수 있습니다. 더 빠른 기능을 제공하십시오!

* 편집 : 여기에 차이점에 대한 기사가 있습니다. https://puppet.com/blog/continuous-delivery-vs-continuous-deployment-what-s-diff 지속적인 전달이 항상 실제로 프로덕션에 배포하는 것을 의미하는 것이 아니라 프로덕션과 같은 환경에 지속적으로 배포하는 것을 의미합니다 비즈니스가 준비되면 언제든지 이러한 변경 사항이 프로덕션으로 전환 될 수 있다는 확신을 가지고 있습니다. 실제로 대부분의 사람들은 이러한 용어를 혼동합니다.


머시! 그러나 당신의 "동일한 것"에 따라, 정말로? 뉘앙스를 보여주는 어떤 것이라도 생각할 수 있습니까?
Pierre.Vriens

차이점에 대한 메모로 게시물을 업데이트했지만 일반적인 대화에서는 대부분의 사람들이이 용어를 서로 바꿔 사용할 것이라고 생각합니다.
tayworm

2

특정 버전의 소프트웨어 제품은 먼저 통합 단계를 완료하여 제공 또는 배포 할 수 있습니다.

대한 지속적인 배달 / 배포 연속 통합은 필수입니다. 그렇지 않으면, 통합 완료 이벤트가 "연속적인"속성을 갖추기에는 너무 멀리 떨어져있는 경우 가능한 배달 / 배치도 가능합니다 (통합 버전의 서브 세트 만 배달 / 배치에 적합 함).

업데이트 : 내 대답은 CI와 CD 모두의 종속성 (관계)에만 밑줄을 긋습니다. 용어는 THelper의 답변으로 잘 설명되어 있습니다.

내가해야 할 유일한 의견은 (오버로드) 사용에 관한 것입니다 deployment. 비 프로덕션 환경에서의 배포는 실제 작업입니다. 예를 들어, 지속적인 배송 중 다양한 테스트 단계의 일부로 자주 수행 될 수도 있습니다. 그러나 그렇다고해서 그러한 배포는 이루어지지 않습니다 continuous deployments. 연속 배포는 구체적으로 프로덕션 환경에서의 배포를 나타냅니다.


좋아, 그게 다 도움이 될지 모르지만 배달 및 배포를 설명하는 방법으로 답변을 확장 할 수 있습니까?
Pierre.Vriens

1

기본적으로 연속 통합은 릴리스가 자동으로 수행된다는 점을 제외하고 지속적 배포 및 연속 배포의 일부입니다. 지속적인 전달은 논리적 통합의 다음 단계로 생각할 수 있으며 모든 환경에서 작동합니다. 지속적인 통합은 또한 아티팩트 검증에 도움이되므로 더 빠르게 배포 할 수 있습니다. 지속적인 통합없이 지속적으로 배포 할 수는 없지만 지속적인 통합으로 버그를 잡는 것이 훨씬 쉽습니다. 이러한“연속적인 것”은 모두 궁극적으로 개발 워크 플로에서 불필요한 작업을 제거하는 것입니다. 가장 중요한 것은 CI / CD는 기술 및 비즈니스 관점에서 중요합니다. 이러한 DevOps 원칙을 채택하지 않은 회사는 공룡을 방해 할 위험이 있습니다. 오늘날의 빠른 IT 환경에서DevOps 또는 사망

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.