이 세 용어의 차이점은 무엇입니까? 우리 대학은 다음과 같은 정의를 제공합니다.

Continuous Integration은 기본적으로 개발자의 작업 사본이 하루에 여러 번 공유 된 메인 라인과 동기화됨을 의미합니다.

Continuous Delivery 는 지속적인 통합의 논리적 발전으로 설명됩니다. 항상 제품을 생산에 투입 할 수 있습니다!

지속적인 배포 는 지속적인 제공 후 논리적 다음 단계로 설명됩니다. QA를 통과 할 때마다 제품을 프로덕션에 자동 배포합니다!

또한 경고를 제공합니다. 테스트 시스템에 지속적으로 배포 할 수있는 경우 "연속 배포"라는 용어가 사용되기도합니다.

이 모든 것이 나를 혼란스럽게한다. 좀 더 자세한 설명이 있거나 설명이 포함 된 설명을 부탁드립니다!

지속적인 통합

나는 당신의 대학의 정의에 동의합니다. 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에 커밋 한 시점부터 파이프 라인이 유효한 릴리스 후보가 있음을 확인한 시점까지 프로세스가 자동화됩니다.

질문이나 대답은 실제로 그것에 대한 나의 간단한 생각과 맞지 않습니다. 저는 컨설턴트이며 이러한 정의를 여러 Dev 팀 및 DevOps 직원과 동기화했지만 업계와 어떻게 일치하는지 궁금합니다.

기본적으로 연속 전달과 같은 민첩한 전달 방식을 생각합니다.

연속적이지 않음 (모든 수동) 0 % ----> 100 % 지속적인 가치 제공 (모든 자동화)

지속적인 전달을위한 단계 :

제로. 개발자가 코드를 체크인 할 때 아무것도 자동화되지 않습니다 ... 체크인 전에 테스트를 컴파일, 실행 또는 수행 한 경우 운이 좋습니다.

1. 연속 빌드 : 모든 체크인에 대한 자동 빌드. 첫 번째 단계이지만 새 코드의 기능적 통합을 증명하는 것은 아닙니다.

2. CI (Continuous Integration) : 기존 코드와 새 코드의 통합을 증명하기위한 최소 단위 테스트의 자동화 된 빌드 및 실행이지만 통합 테스트 (end-to-end)가 바람직합니다.

3. CD (Continuous Deployment) : 코드가 CI를 최소한 테스트 환경으로 통과 할 때 자동 배포, 바람직하게는 CI를 통해 품질이 입증되거나 수동 테스트 후 낮은 환경을 통과로 표시하면 더 높은 환경으로 배포됩니다. IE의 경우 테스트가 수동 인 경우도 있지만 다음 환경으로의 승격은 자동입니다.

4. 지속적인 제공 : 시스템을 생산에 자동 게시 및 릴리스합니다. CD는 프로덕션 환경의 CD이며 A / B 테스트 설정, 새로운 기능에 대한 사용자 알림, 새 버전 지원 및 변경 사항 알림 등과 같은 기타 구성 변경 사항입니다.

편집 : Agile Manifesto의 첫 번째 원칙 ( http://agilemanifesto.org/principles.html ) 에서 언급 한 "연속 전달"개념과 지속적인 전달 관행 사이에 차이가 있음을 지적하고 싶습니다 . 질문의 맥락에서 참조 된 것처럼 보입니다. 지속적인 전달의 원칙은 린 (Lean) 사고 ( http://www.miconleansixsigma.com/8-wastes.html )에 설명 된대로 재고 낭비를 줄이기 위해 노력하는 것 입니다. 민첩한 팀이 CD (Continuous Delivery)를 실행 한 것은 2001 년 민첩한 선언문이 작성된 이후 몇 년 동안 등장했습니다.

아마존 정의 는 간단하고 이해하기 쉽다고 생각 합니다.

" Continuous Delivery 는 릴리스 프로세스가 자동화되는 소프트웨어 개발 방법론입니다. 모든 소프트웨어 변경은 자동으로 빌드, 테스트 및 프로덕션에 배포됩니다. 프로덕션으로 최종 푸시하기 전에 개인, 자동화 된 테스트 또는 비즈니스 규칙이 결정됩니다. 모든 성공적인 소프트웨어 변경 사항을 지속적으로 제공하여 즉시 프로덕션으로 릴리스 할 수 있지만 모든 변경 사항을 즉시 릴리스 할 필요는 없습니다.

지속적인 통합 은 팀 구성원이 버전 제어 시스템을 사용하고 작업을 마스터 지점과 같은 동일한 위치에 자주 통합하는 소프트웨어 개발 관행입니다. 각 변경 사항은 가능한 빨리 통합 오류를 감지하기 위해 테스트 및 기타 검증을 통해 구축 및 검증됩니다. 지속적인 통합은 전체 소프트웨어 릴리스 프로세스를 생산까지 자동화하는 지속적인 제공과 비교하여 자동으로 코드를 작성하고 테스트하는 데 중점을두고 있습니다. "

http://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html을 확인 하십시오

Atlassian은 지속적인 통합과 지속적인 배포, 지속적인 배포에 대한 좋은 설명을 게시했습니다 .

간단히 말해서 :

Continuous Integration- 새로운 커밋이 지점으로 푸시 될 때마다 애플리케이션을 빌드하고 테스트하는 자동화입니다.

Continuous Delivery – 지속적인 통합 + "버튼 클릭"을 통해 프로덕션에 응용 프로그램 배포

지속적인 배포 - 지속적인 전달 이지만 사람의 개입이 없습니다 (고객에 대한 릴리스가 진행 중임).

Continuous Integration은 기본적으로 개발자의 작업 사본이 하루에 여러 번 공유 된 메인 라인과 동기화됨을 의미합니다.

또는 하루에 여러 번 이상. 주어진 개별 작업이 기본적으로 완료되는 한 자주. 예를 들어 단일 비즈니스 애플리케이션에서 작업하는 개발자 팀을 고려하십시오. 많은 환경에서 다음이 발생할 수 있습니다.

• "아직 준비되지 않았기"때문에 한두 명의 개발자가 며칠 동안 로컬 변경을 유지합니다.
• 한두 명의 개발자가 소스 제어에서 분기를 작성하여 "다른 사람의 변경에 방해받지 않고"기능을 수행 할 수 있습니다.

문제가 발생할 수 있습니다. 불완전한 코드 / 작업 조직은 분기로 이어지고 분기는 병합, 병합으로 이어집니다. 실무로서의 지속적인 통합은 모든 사람이 동일한 공유 소스에서 작업하도록 장려함으로써이를 해결합니다. 개별 작업 항목은 짧은 시간 (최대 1 시간) 내에 완료 될 수있을 정도로 분리되어야합니다.

기본적으로 일반적인 아이디어는 적은 양의 작업으로 작은 변화를 통합하는 것입니다. 큰 변화를 통합하는 것은 불균형 적으로 많은 양의 작업입니다. 지속적으로 작은 단계를 수행하면 통합 작업의 총합이 더 작아집니다. 이를 통해 개발자는 개발 프로세스 오버 헤드 대신 비즈니스 가시적 기능에 더 많은 시간을 할애 할 수 있습니다.

Continuous Delivery는 지속적인 통합의 논리적 발전으로 설명됩니다. 항상 제품을 생산에 투입 할 수 있습니다!

이것은 개별적이고 잘 정의 된 작업 항목에 대한 동일한 아이디어를 따릅니다. 완벽하고 테스트를 거친 알려진 작동 기능으로 조금씩만 조정되는 단일 마스터 코드베이스가있는 경우 해당 코드베이스는 항상 안정적입니다. 버튼을 누를 때 안정성을 입증 할 수있는 자동화 된 테스트가 여기에 있습니다.

수행해야 할 안정화 작업이 적을수록 (다시 개발 프로세스 오버 헤드이며 제거해야 함) 코드베이스를 특정 환경으로 푸시 할 수있는 빈도가 높아집니다. 많은 회사에서 배포는 매우 거친 프로세스 일 수 있습니다. 일주일 내내 모든 데크 작업이 가능합니다. 이것은 비싸고 비즈니스 가치를 창출하지 않습니다. 우수한 작업 항목 정의, 효과적인 자동 테스트 및 지속적인 통합을 통해 팀은 주어진 환경으로의 코드베이스 전달을 자동화 할 수 있습니다.

지속적인 배포는 지속적인 제공 후 논리적 다음 단계로 설명됩니다. QA를 통과 할 때마다 제품을 프로덕션에 자동 배포합니다!

비즈니스 환경에서는 이런 일이 거의 발생하지 않으며, 만나면 매우 기쁩니다. 코드베이스가 자동으로 테스트되고 주어진 환경에 자동으로 배포 될 수 있다면 프로덕션은 다른 환경과 같습니다. 따라서 팀이이 시점까지 구축 한 경우 항상 프로덕션에 업데이트를 배포 할 수있어 비즈니스에 상당한 가치가있을 수 있습니다.

결함 수정은 고객에게 더 빨리 전송되고, 새로운 기능은 더 빨리 시장에 도달하며, 새로운 아이디어는 우선 순위 등의 리디렉션을 허용하기 위해 더 작은 단위로 시장에 대해 테스트됩니다.

예를 들어, 회사가 소프트웨어 기반 제품 또는 서비스의 새로운 기능에 대해 큰 아이디어를 가지고 있다고 가정합니다. 그들은 약간의 연구를 해왔고 시장을 알고 있으며,이 아이디어가 강력한 새로운 수익을 창출 할 것이라고 믿습니다. 이제 해당 기능을 제공하기위한 두 가지 옵션을 고려하십시오.

1. 일회성 지점에서 모든 것을 개발하는 데 몇 달을 보냅니다. 기본 코드베이스에 다시 통합하는 데 몇 주가 걸립니다. 그것을 며칠 동안 보내십시오. 그것을 배치하는 데 하루를 보내십시오. 그런 다음에 만 프로덕션 시스템에서 실제 수익 추적 을 시작하십시오.
2. 기능의 작은 부분을 한 번에 하나씩 구현하십시오. 매주 새로운 조각을 발표합니다. 매주 실제 수익에 대한 더 많은 데이터를 얻습니다.

첫 번째 시나리오에서이 기능에 원하는 시장 효과 가 없으면 고객이 실제로 원하지 않는 것에 많은 돈이 낭비됩니다. 두 번째 시나리오에서 고객이 원하지 않는 사실은 훨씬 더 일찍 결정되며 나머지 작업은 우선 순위가 낮습니다.

궁극적으로 이러한 "연속적인 것"은 모두 개발 프로세스 오버 헤드를 제거하는 것입니다. 회사의 매출 라인이 특정 서비스 오퍼링 인 경우 이상적으로 모든 비용이 해당 오퍼링에 들어가야합니다. 개발 프로세스 오버 헤드 (코드 병합, 병합 후 동일한 기능 다시 테스트, 수동 배포 작업 등)는 실제로 서비스 가치에 영향을 미치지 않으므로 이러한 개념은 프로세스에서 이러한 비용을 제거하려고합니다.

하나의 그래프가 많은 단어를 대체 할 수 있습니다.

즐겨! :-)

# 올바른 이미지를 업데이트했습니다 ...

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

나는 우리가 "연속적인"단어 모음을 분석하고 어쩌면 복잡하게 만들고 있다고 생각합니다. 이러한 맥락에서 연속은 자동화를 의미합니다. "연속"에 첨부 된 다른 단어는 영어를 번역 가이드로 사용하고 복잡한 것을 시도하지 마십시오! "연속 빌드"에서는 특정 플랫폼 / 컨테이너 / 런타임 등을 위해 실행 가능한 것으로 애플리케이션을 자동으로 빌드 (쓰기 / 컴파일 / 링크 / 등)합니다. "지속적인 통합"이란 새로운 기능이 다른 엔티티와 상호 작용할 때 의도 한대로 테스트하고 수행함을 의미합니다. 분명히 통합이 이루어지기 전에 빌드가 이루어져야하며 철저한 테스트를 통해 통합의 유효성을 검사해야합니다. "연속 통합"에서 하나는 자동화를 사용하여 기존 기능 버킷에 가치를 추가하여 기존 기능을 부정적으로 방해하지 않고 기능과 잘 통합하여 인식 된 가치를 전체에 추가합니다. 통합은 단순한 영어 정의에 의해 코드 대화에서 조화롭게 움직여서 추가 컴파일, 링크, 테스트 및 전체적으로 완벽하게 실행됩니다. 최종 제품이 고장 나더라도 통합 된 것을 호출하지 않겠습니까?! 우리의 맥락에서 "Continuous deployment"는 "continuos delivery"와 동의어입니다. 하루가 끝날 때 고객에게 기능을 제공했기 때문입니다. 그러나 이것을 분석함으로써 배포가 배달의 하위 집합이라고 주장 할 수 있습니다. 왜냐하면 무언가를 배포한다고해서 반드시 전달한 것은 아닙니다. 우리는 코드를 배포했지만 우리는 이해 관계자들에게 효과적으로 의사 소통을했지만 비즈니스 관점에서 전달하지 못했습니다! 우리는 군대를 배치했지만 약속 된 물과 음식을 인근 도시로 전달하지 않았습니다. "연속 전환"이라는 용어를 추가하려면 자체 장점이 있습니까? 결국, 한 위치만을 의미 할 수있는 배치 또는 전달보다 "시작 / 종료"라는 의미가 있기 때문에 환경을 통한 코드 이동을 설명하는 것이 더 적합 할 수 있습니다. 상식을 적용하지 않으면 얻을 수있는 것입니다. 자체 장점이 있습니까? 결국, 한 위치만을 의미 할 수있는 배치 또는 전달보다 "시작 / 종료"라는 의미가 있기 때문에 환경을 통한 코드 이동을 설명하는 것이 더 적합 할 수 있습니다. 상식을 적용하지 않으면 얻을 수있는 것입니다. 자체 장점이 있습니까? 결국, 한 위치만을 의미 할 수있는 배치 또는 전달보다 "시작 / 종료"라는 의미가 있기 때문에 환경을 통한 코드 이동을 설명하는 것이 더 적합 할 수 있습니다. 상식을 적용하지 않으면 얻을 수있는 것입니다.

결론적으로, 이것은 설명하기 쉬운 것입니다 (약간 복잡합니다!), 상식과 영어를 사용하면 괜찮을 것입니다.

지속적인 통합 : 개발 작업을 메인 브랜치와 지속적으로 병합하여 코드를 가능한 한 자주 테스트하여 문제를 조기에 파악하도록합니다.

연속 전달 : 코드를 배송 할 준비가되면 환경에 코드를 지속적으로 전달합니다. 준비 또는 프로덕션 일 수 있습니다. 아이디어는 제품이 사용자 기반으로 전달되어 검토 및 검사를 위해 QA 또는 고객이 될 수 있다는 것입니다.

Continuous Integration 단계에서의 단위 테스트는 모든 버그와 비즈니스 로직, 특히 QA가 필요한 설계 문제 또는 테스트를위한 스테이징 환경을 파악할 수 없습니다.

연속 배포 : 준비되는 즉시 코드 배포 또는 릴리스. Continuous Deployment에는 Continuous Integration 및 Continuous Delivery가 필요합니다. 그렇지 않으면 릴리스에서 코드 품질이 보장되지 않습니다.

지속적인 배포 ~~ 지속적인 통합 + 지속적인 전달

지속적인 통합

• 자동화 (체크인 + 단위 테스트 구축)

지속적인 배달

• 지속적인 통합
• 자동화 (테스트 환경 구축 +로드 테스트 + 통합 테스트)
• 수동 (생산 배치)

지속적인 배포

• 지속적인 배송 이지만 자동화 (생산에 대한 배포)

CI / CD는 여행입니다. 목적지가 아닙니다.

이 단계는 제안입니다. 비즈니스 요구에 따라 단계를 조정할 수 있습니다. 여러 유형의 테스트, 보안 및 성능을 위해 일부 단계를 반복 할 수 있습니다. 프로젝트의 복잡성과 팀 구조에 따라 일부 단계는 여러 수준에서 여러 번 반복 될 수 있습니다. 예를 들어, 한 팀의 최종 제품은 다음 팀의 프로젝트에서 의존성이 될 수 있습니다. 즉, 첫 번째 팀의 최종 제품은 다음 팀 프로젝트에서 아티팩트로 준비됩니다.

각주 :

AWS에서 지속적인 통합 및 지속적인 제공

출처 : https://thenucleargeeks.com/2020/01/21/continuous-integration-vs-continuous-delivery-vs-continuous-deployment/

지속적인 통합이란 지속적인 통합은 자동화 된 빌드 및 자동화 된 테스트의 프로세스 또는 개발 방식입니다. 즉, 개발자는 자동화 된 빌드 및 테스트를 통해 각 통합을 확인하는 공유 저장소에 코드를 여러 번 커밋해야합니다.

빌드가 실패 / 성공하면 개발자에게 통지 된 후 관련 조치를 취할 수 있습니다.

Continuous Delivery 란 Continuous Delivery는 모든 테스트를 통과하고 코드를 프로덕션으로 푸시하기 위해 필요한 모든 구성이 있지만 아직 배포되지 않은 시점에 코드를 배포 할 수있는 방식입니다.

지속적인 배포 란 무엇입니까 CI의 도움으로 우리는 응용 프로그램을위한 빌드를 만들었으며 프로덕션 환경으로 넘어갈 준비가되었습니다. 이 단계에서는 빌드가 준비되었으며 CD를 사용하여 애플리케이션을 QA 환경에 직접 배포 할 수 있으며 모든 것이 제대로 진행되면 동일한 빌드를 프로덕션에 배포 할 수 있습니다.

따라서 기본적으로 지속적인 배포는 지속적인 배포보다 한 단계 더 발전했습니다. 이를 통해 생산 파이프 라인의 모든 단계를 통과하는 모든 변경 사항이 고객에게 릴리스됩니다.

지속적인 배포는 구성 관리 및 컨테이너화의 조합입니다.

구성 관리 : CM은 응용 프로그램 요구 사항과 호환되는 서버 구성을 유지 관리하는 것입니다.

컨테이너화 : 컨테이너화는 환경 전체에서 일관성을 유지하는 일련의 통행료입니다.

Img 출처 : https://www.atlassian.com/

DevOps는 3C의 지속적인 , 커뮤니케이션 , 협업 의 조합으로 다양한 산업 분야에 중점을두고 있습니다.

IoT 연결 장치 세계에서 제품 소유자, 웹, 모바일 및 QA와 같은 여러 스크럼 기능은 스크럼주기의 스크럼에서 민첩한 방식으로 작동하여 최종 고객에게 제품을 제공합니다.

지속적인 통합 : 여러 엔드 포인트에서 동시에 작동하는 여러 스크럼 기능

지속적인 제공 : 통합 및 배포를 통해 여러 고객에게 동시에 제품을 제공 할 수 있습니다.

지속적인 배포 : 여러 플랫폼에서 여러 고객에게 배포 된 여러 제품.

IoT 연결 세계를 구현하는 DevOps를 확인하려면 https://youtu.be/nAfZt2t4HqA

Continuous Delivery & DevOps 과정에서 Alex Cowan과 함께 배운 내용 에서 CI와 CD는 관찰에서 출시 된 제품으로 전환되는 시간으로 구성된 제품 파이프 라인의 일부입니다.

관찰에서 디자인까지 목표는 고품질의 테스트 가능한 아이디어를 얻는 것입니다. 프로세스의이 부분은 연속 디자인 으로 간주됩니다 .

우리는 이후 코드에서 이동하면 어떻게 그것이 간주, 후 발생하는 연속 배달 누구의 목표 (당신이 겸손의 예약 제즈을 읽을 수있는 매우 빠르게 고객에게 아이디어와 릴리스를 실행하는 기능 연속 배달 : 빌드를 통해 신뢰성있는 소프트웨어 릴리즈를 테스트, 자세한 내용은 배포 자동화) 를 참조하십시오. 다음 파이프 라인은 CI (Continuous Integration) 및 CD (Continuous Delivery)로 구성되는 단계를 설명합니다.

지속적인 통합 으로 마티아스 페터 요한슨은 설명한다 ,

소프트웨어 팀이 하루에 여러 번 병합을 수행하는 습관이 있고 해당 병합에서 문제를 확인하는 자동 확인 시스템을 갖추고있는 경우입니다.

CircleCI- CircleCI-Continuous Integration P2 시작 및 Pull Request에서 CircleCI 실행을 사용하여보다 실질적인 개요를 보려면 다음 두 비디오를 볼 수 있습니다 .

CI / CD 파이프 라인을 다음과 같이 지정할 수 있으며, 새 코드에서 릴리스 된 제품으로 이동합니다.

처음 세 단계는 테스트 대상과 관련이있는 테스트와 관련이 있습니다.

반면에 연속 배포 는 배포를 자동으로 처리하는 것입니다. 따라서 자동화 된 테스트 단계를 통과 한 모든 코드 커밋은 프로덕션에 자동으로 릴리스됩니다.

참고 : 파이프 라인이 꼭 필요한 것은 아니지만 참조로 사용할 수 있습니다.