지속적인 통합

나는 당신의 대학의 정의에 동의합니다. Continuous Integration 은 개발자가 자주하는 것이 아니라 지속적으로 코드를 메인 라인에 지속적으로 통합하는 방법입니다.

버전 관리 시스템에서는 단순히 브랜칭 전략이라고 주장 할 수 있습니다.

개발자에게 할당하는 작업의 크기와 관련이 있습니다. 작업이 4-5 일 정도 소요될 것으로 예상되는 경우 개발자는 아직 아무 것도하지 않았기 때문에 다음 4-5 일 동안 아무것도 제공하지 않을 것입니다.

따라서 크기가 중요합니다.

small task = continuous integration
big task   = frequent integration

이상적인 작업 크기는 하루 작업량보다 크지 않습니다. 이런 식으로 개발자는 하루에 한 번 이상 통합 할 수 있습니다.

지속적인 배달

Continuous Delivery 에는 기본적으로 3 개의 학교가 있습니다.

Continuous Delivery는 Continuous Integration의 자연스러운 확장입니다.

이 학교, 상기 외모 애디슨 – 웨슬리 “마틴 파울러”서명 시리즈 와 2007 릴리스가 호출 된 이후 있다는 가정을 만든다 “지속적인 통합” 과 2011 년에 이어 하나가 불렀다 “연속 배달” 그들은 아마도 볼륨있는 1 + 2 지속적인 무언가 와 관련이있는 동일한 개념적인 아이디어 .

지속적인 제공은 애자일 소프트웨어 개발과 관련이 있습니다

이 학교는 Continuous Delivery가 개념적인 아이디어 나 의도 의 서신 뿐만 아니라 실제 생활을위한 민첩한 운동의 원칙을 지원할 수 있다는 것에서 시작됩니다 .

“연속 배송”이라는 용어가 실제로 처음으로 사용되는 애자일 선언문 의 첫 번째 원칙에서 상쇄되는 경우 :

우리의 최우선 과제는 귀중한 소프트웨어를 조기에 지속적으로 제공함으로써 고객을 만족시키는 것입니다.

이 학교는 “Continuous Delivery”는 “완료된 정의”에 대한 자동 검증을 구현하는 데 필요한 모든 것을 포함하는 패러다임이라고 주장합니다 .

이 학교는 “지속적인 배달”과 버즈 단어 또는 메가 트렌드 “DevOps” 가 기술이 아니라이 새로운 패러다임이나 접근 방식을 포용하거나 캡슐화하려고한다는 의미에서 동일한 동전의 뒤집힌 부분임을 인정합니다.

Continuous Delivery는 Continuous Deployment와 동의어입니다.

세 번째 학교는 Continuous Deployment 와 Continuous Delivery 를 같은 의미로 교환하여 사용할 수 있다고 주장합니다 .

개발자가 준비한 것이 있으면 최종 사용자에게 즉시 전달되므로 대부분 프로덕션 환경에 배포해야합니다. 따라서 “배포”와 “배달”은 동일합니다.

가입 할 학교

귀하의 대학은 첫 번째 학교에 분명히 입학했으며 동일한 출판물 시리즈의 1 + 2 권을 언급한다고 주장합니다. 내 의견은 이것이 Continuous Delivery라는 용어의 오용이라는 것입니다.

본인은 Continuous Delivery 가 민첩한 움직임으로 표현 된 아이디어와 개념에 대한 실제 지원을 구현하는 것과 관련이 있다는 점을 개인적으로 옹호합니다 . 그래서 저는이 용어가 “DevOps”와 같은 전체 패러다임을 포용한다고 말하는 학교에 합류했습니다.

사용하는 학교에 전달 하는 동의어로 배포는 주로 용어의보다 광범위한 사용에서 과대 광고의 비트를 얻으려고 노력, 배포 콘솔을 만드는 툴 벤더에 의해 주창되어 연속 배달 .

지속적인 배포

Continuous Deployment에 대한 초점은 소프트웨어 업데이트에 대한 최종 사용자의 액세스가이 정보에 대한 일부 중앙 소스 업데이트에 의존하고이 중앙 소스가 모 놀리식이거나 일관성이 높기 때문에 항상 업데이트하기 쉽지 않은 도메인과 관련이 있습니다. 본질적으로 (웹, SOA, 데이터베이스 등).

중앙 집중식 정보 소스 (장치, 소비자 제품, 클라이언트 설치 등)가 없거나 중앙 집중식 정보 소스 (업데이트 관리 시스템, 오픈 소스 리포지토리 등)가있는 소프트웨어를 생산하는 많은 도메인의 경우 ), 연속 배포라는 용어에 대해서는 과대 광고가 거의 없습니다. 그들은 단지 배치합니다; 그것은 큰 일이 아닙니다-특별한 초점이 필요한 고통이 아닙니다.

Continuous Deployment가 모든 사람에게 일반적으로 흥미로운 것이 아니라는 사실은 “배달”과 “배포”가 동의어라고 주장하는 학교가 모두 잘못했다고 주장합니다. Continuous Delivery는 실제로 장치에 내장 된 소프트웨어를 사용하거나 프레임 워크 용 오픈 소스 플러그인을 출시하더라도 모든 사람에게 완벽하게 적합합니다.

Continuous Deployment가 자연스러운 Continuous Delivery의 다음 단계라는 대학의 정의는 QA가 된 모든 배달이 최종 사용자가 즉시 사용할 수 있어야한다는 것을 암시 적으로 가정합니다. Release “는 결국 모든 사람에게 의미가없는 또 다른 개념입니다.

릴리스는 매우 전략적이거나 정치적 일이 될 수 있으며 온라인 서점에서 스트리밍 서비스 유형의 회사가 아닌 한 모든 사람이 항상이 작업을 원한다고 가정 할 이유가 없습니다. 그럼에도 불구하고 항상 맹목적으로 모든 것을 공개하지 않는 회사는 어쨌든 배포 마스터가 되려는 이유가 많을 수 있으므로 연속 배포 도 마찬가지 입니다. 하지 생산하지만 릴리스의 릴리스 후보 에 대한 생산과 같은 환경.

다시 한 번 나는 당신의 대학이 잘못했다고 생각합니다. 그들은 “연속 배포”에 대해 “연속 배포”를 착각하고 있습니다.

지속적인 배포는 단순히 개발 프로세스의 결과를 기능 테스트를 전체 규모로 실행할 수있는 프로덕션 환경으로 지속적으로 옮길 수있는 원칙입니다.

지속적인 전달 스토리

사진에서 그것은 모두 살아있다 :

연속 통합 프로세스는 상태 전이 다이어그램에서 처음 두 작업입니다. 성공한 경우 done 의 정의 를 구현하는 Continuous Delivery 파이프 라인을 시작 합니다 . 배포는이 파이프 라인에서 지속적으로 수행해야하는 많은 작업 중 하나 일뿐입니다. 이상적으로는 개발자가 VCS에 커밋 한 시점부터 파이프 라인이 유효한 릴리스 후보가 있음을 확인한 시점까지 프로세스가 자동화됩니다.

---

답변