지속적 배포
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
지속적 배포(CD)는 소프트웨어의 릴리스 프로세스를 자동화하는 소프트웨어 공학적 접근 방식이다. 닐 포드에 따르면, CD는 어려운 작업을 초기에 처리하고, 자동화를 촉진하며, 신속한 문제 감지를 통해 "고통을 앞으로 가져오는" 방식을 채택한다. CD는 배포 파이프라인을 통해 구현되며, 가시성, 피드백, 지속적인 배포의 세 가지 구성 요소를 갖는다. CD는 DevOps와 밀접한 관련이 있으며, 시장 출시 시간 단축, 제품 품질 향상, 고객 만족도 증대 등의 이점을 제공하지만, 테스트 자동화 부족, 고객 선호도, 도메인 제한 등의 과제도 존재한다. CD 채택을 위한 전략으로는 전담 팀 구성, 쉬운 애플리케이션부터 시작하기 등이 있으며, 클라우드 환경에서는 파이프라인 수와 권한 관리가 중요하다.
더 읽어볼만한 페이지
- 소프트웨어 설계 - 구조적 분석
구조적 분석은 1960년대에서 1980년대 소프트웨어 개발의 복잡성을 해결하기 위해 개발된 기법으로, 다이어그램과 데이터 사전을 활용하여 시스템을 분석하고 설계했으며, 객체 지향 프로그래밍의 등장으로 활용도가 감소했다. - 소프트웨어 설계 - 도메인 주도 설계
도메인 주도 설계는 소프트웨어 개발에서 문제 해결 영역인 도메인의 중요성을 강조하며, 도메인 전문가와 개발자의 협력을 통해 도메인 모델을 구축하여 소프트웨어의 복잡성 관리와 일관성 유지를 목표로 하는 방법론이다. - 소프트웨어 개발 프로세스 - 버전 관리
버전 관리는 파일 변경 이력을 체계적으로 관리하는 시스템이며, 다양한 구조와 소스 관리 모델을 통해 협업을 지원하고, 비즈니스 등 다양한 분야에서 활용된다. - 소프트웨어 개발 프로세스 - 소프트웨어 개발 수명 주기
소프트웨어 개발 수명 주기(SDLC)는 시스템 설계자와 개발자가 따르는 일련의 단계로, 예비 분석부터 폐기까지 여러 단계를 거치며, 폭포수 모델, 시스템 분석 및 설계(SAD), 객체 지향 분석 및 설계(OOAD) 등 다양한 방법론을 포함한다.
| 지속적 배포 | |
|---|---|
| 개요 | |
 | |
| 정의 | 소프트웨어 개발 방식 |
| 목표 | 소프트웨어 변경 사항을 빠르고 안전하게 릴리스하는 것 |
| 핵심 원칙 | 빌드 자동화 테스트 자동화 릴리스 자동화 |
| 상세 내용 | |
| 주요 단계 | 코드 커밋 빌드 테스트 릴리스 |
| 사용 기술 | 지속적 통합 (CI) 자동화된 테스트 구성 관리 가상화 클라우드 컴퓨팅 |
| 장점 | 빠른 릴리스 주기 낮은 위험 높은 품질 빠른 피드백 |
| 단점 | 높은 초기 투자 비용 조직 문화 변화 필요 자동화 도구에 대한 의존성 증가 |
| 관련 용어 | DevOps 지속적 통합 (CI) 지속적 배포 (CD) |
| 접근 방식 | |
| 일반적인 파이프라인 단계 | 커밋: 코드가 버전 제어 리포지토리에 커밋되면 파이프라인이 트리거됩니다. 빌드: 소프트웨어가 빌드됩니다. 테스트: 소프트웨어가 테스트됩니다. 릴리스: 소프트웨어가 프로덕션에 릴리스됩니다. |
2. 원칙
닐 포드는 지속적 배포는 어려운 작업을 초기에 처리하고, 자동화를 촉진하며, 신속한 문제 감지를 통해 "고통을 앞으로 가져오는" 방식을 채택한다고 설명한다.[3]
지속적 배포는 ''배포 파이프라인''[4]이라는 개념을 통해 구현된다. 배포 파이프라인은 린 소프트웨어 개발에서 포카요케로 취급된다.[5] 이는 소프트웨어가 소프트웨어 릴리스 과정에서 거치는 일련의 검증 단계를 의미한다.
지속적 배포는 일반적인 개념인 ''배포 파이프라인''[4]을 린 소프트웨어 개발의 포카요케로 취급한다.[5] 이는 소프트웨어가 소프트웨어 릴리스를 향해 나아가는 과정에서 통과해야 하는 일련의 검증 집합이다. 변경 사항이 소스 제어 저장소에 커밋될 때마다 필요한 경우 코드가 컴파일되고 빌드 서버에 의해 패키징된 다음, 릴리스 가능으로 표시되기 전에 여러 가지 기술(수동 테스트 포함)로 테스트된다.
긴 주기에 익숙한 개발자는 지속적 배포(CD) 환경에서 작업할 때 사고방식을 바꿔야 할 수 있다. 모든 코드 커밋은 언제든지 고객에게 릴리스될 수 있기 때문이다. 기능 토글과 같은 패턴은 최종 사용자가 아직 사용할 준비가 되지 않은 코드를 초기에 커밋하는 데 매우 유용할 수 있다. NoSQL을 사용하면 종종 수동 단계이거나 지속적 배포 워크플로우의 예외인 데이터 마이그레이션 및 스키마 변경 단계를 제거할 수 있다.[6] 코드 브랜치와 같이 격리된 상태에서 코드를 개발하는 데 유용한 다른 기술은 CD 환경에서도 쓸모가 없어지는 것은 아니지만, CD의 원칙에 맞게 조정되어야 한다. 예를 들어, 여러 개의 장기간 실행되는 코드 브랜치를 실행하는 것은 실용적이지 않을 수 있다. 릴리스 가능한 아티팩트가 파이프라인의 모든 단계를 통과하려면 단일 코드 브랜치에서 CD 프로세스 초기에 빌드되어야 하기 때문이다.
3. 배포 파이프라인
얀 추이(Yan Cui)에 따르면, 서버리스 컴퓨팅 환경에서 임시 리소스는 높은 응집도 (컴퓨터 과학)를 위해 자체 배포 파이프라인을 가져야 한다. 반면, 스핀업 시간이 길고 랜딩존이 있는 공유 리소스는 별도의 저장소 (버전 관리), 배포 파이프라인 및 스택을 가져야 한다.[8]
3. 1. 구성 요소
지속적 배포는 배포 파이프라인을 통해 가능해진다. 배포 파이프라인은 가시성, 피드백, 지속적인 배포라는 세 가지 구성 요소를 갖는다.[7]3. 2. 작동 방식
닐 포드에 따르면, 지속적 배포는 어려운 작업을 초기에 처리하고, 자동화를 촉진하며, 신속한 문제 감지를 통해 "고통을 앞으로 가져오는" 방식을 채택한다.[3]
지속적 배포는 일반적인 개념인 ''배포 파이프라인''[4]을 린 소프트웨어 개발의 포카요케로 취급한다.[5] 이는 소프트웨어가 소프트웨어 릴리스를 향해 나아가는 과정에서 통과해야 하는 일련의 검증 집합이다. 변경 사항이 소스 제어 저장소에 커밋될 때마다 필요한 경우 코드가 컴파일되고 빌드 서버에 의해 패키징된 다음, 릴리스 가능으로 표시되기 전에 여러 가지 기술(수동 테스트 포함)로 테스트된다.
긴 주기에 익숙한 개발자는 CD 환경에서 작업할 때 사고방식을 바꿔야 할 수 있다. 모든 코드 커밋은 언제든지 고객에게 릴리스될 수 있다. 기능 토글과 같은 패턴은 최종 사용자가 아직 사용할 준비가 되지 않은 코드를 초기에 커밋하는 데 매우 유용할 수 있다. NoSQL을 사용하면 종종 수동 단계이거나 지속적 배포 워크플로우의 예외인 데이터 마이그레이션 및 스키마 변경 단계를 제거할 수 있다.[6] 코드 브랜치와 같이 격리된 상태에서 코드를 개발하는 데 유용한 다른 기술은 CD 환경에서도 쓸모가 없어지는 것은 아니지만, CD의 원칙에 맞게 조정되어야 한다. 예를 들어, 여러 개의 장기간 실행되는 코드 브랜치를 실행하는 것은 실용적이지 않을 수 있다. 릴리스 가능한 아티팩트가 파이프라인의 모든 단계를 통과하려면 단일 코드 브랜치에서 CD 프로세스 초기에 빌드되어야 하기 때문이다.
지속적 배포는 배포 파이프라인을 통해 가능해진다. 배포 파이프라인의 목적은 세 가지 구성 요소로 구성된다.[7]
| 구성 요소 | 설명 |
|---|---|
| 가시성 | 빌드, 배포, 테스트 및 릴리스를 포함한 제공 시스템의 모든 측면은 팀의 모든 구성원에게 공개되어 협업을 촉진한다. |
| 피드백 | 팀 구성원은 문제가 발생하면 가능한 한 빨리 문제를 파악하여 가능한 한 빨리 수정할 수 있다. |
| 지속적인 배포 | 완전히 자동화된 프로세스를 통해 모든 버전의 소프트웨어를 모든 환경에 배포하고 릴리스할 수 있다. |
얀 추이(Yan Cui)에 따르면, 서버리스 컴퓨팅 환경의 경우, 임시 리소스는 함께 유지되어 높은 응집도 (컴퓨터 과학)를 달성하기 위해 자체 배포 파이프라인을 가져야 한다. 그러나 스핀업 시간이 길고 랜딩존이 있는 공유 리소스는 자체적인 별도의 저장소 (버전 관리), 배포 파이프라인 및 스택을 가져야 한다.[8]
4. 도구
지속적 배포는 소스 제어부터 프로덕션에 이르기까지 자동화를 수행한다. 이 프로세스의 전체 또는 일부를 수행하는 데 도움이 되는 다양한 도구가 있다.[9] 이러한 도구는 지속적 배포를 포함하는 배포 파이프라인의 일부이다. 프로세스의 다양한 부분을 실행하는 도구 유형에는 지속적 통합, 애플리케이션 릴리스 자동화, 빌드 자동화, 애플리케이션 수명 주기 관리 등이 있다.[10]
5. 지속적 배포와의 관계
지속적 배포(Continuous Deployment)는 자동화된 소프트웨어 배포를 사용하는 소프트웨어 공학적 접근 방법이다.[40] 소프트웨어를 짧은 주기로 생산하되, 마지막 제품 단계까지 자동화된 소프트웨어 배포 과정을 거친다. 따라서 지속적 배포는 보다 정교한 자동화 형태로 볼 수 있다.[41] 학술 문헌에서는 배포 방식(수동 혹은 자동)에 따라 지속적 전달과 지속적 배포를 구분하고 있다.[2][27]
닐 포드에 따르면, 지속적 배포는 어려운 작업을 초기에 처리하고, 자동화를 촉진하며, 신속한 문제 감지를 통해 "고통을 앞으로 가져오는" 방식을 채택한다.[3]
지속적 배포는 ''배포 파이프라인''[4]을 린 소프트웨어 개발의 포카요케로 취급한다.[5] 변경 사항이 소스 제어 저장소에 커밋될 때마다 필요한 경우 코드가 컴파일되고 빌드 서버에 의해 패키징된 다음, 릴리스 가능으로 표시되기 전에 여러 가지 기술(수동 테스트 포함)로 테스트된다.
긴 주기에 익숙한 개발자는 지속적 배포 환경에서 작업할 때 사고방식을 바꿔야 할 수 있다. 모든 코드 커밋은 언제든지 고객에게 릴리스될 수 있기 때문이다. 기능 토글과 같은 패턴은 최종 사용자가 아직 사용할 준비가 되지 않은 코드를 초기에 커밋하는 데 매우 유용할 수 있다. NoSQL을 사용하면 종종 수동 단계이거나 지속적 배포 워크플로우의 예외인 데이터 마이그레이션 및 스키마 변경 단계를 제거할 수 있다.[6] 코드 브랜치와 같이 격리된 상태에서 코드를 개발하는 데 유용한 다른 기술은 지속적 배포 환경에서도 유용하지만, 지속적 배포의 원칙에 맞게 조정되어야 한다.
지속적 배포와 DevOps는 의미가 비슷하여 혼동되는 경우가 많지만, 서로 다른 개념이다.[32] DevOps는 더 넓은 범위를 가지며,[33] 문화적 변화와 소프트웨어 배포 프로세스의 자동화를 중심으로 한다. 한편, 지속적 배포는 배포 측면을 자동화하는 접근 방식으로, 서로 다른 프로세스를 통합하여 더 빠르고 빈번하게 실행하는 데 중점을 둔다.[34]
지속적 딜리버리란 수동 릴리스를 통해 언제든지 배포할 수 있는 소프트웨어를 전달하는 능력이다. 이는 자동 배포를 사용하는 지속적 배포와는 대조적이다.[35] 마틴 파울러에 따르면, 지속적 배포에는 지속적 딜리버리가 필요하다.[36]
6. DevOps와의 관계
데브옵스는 소프트웨어 개발 접근 방식의 하나로, 소프트웨어 제공과 관련된 다양한 팀(개발자, 운영, 품질 보증, 관리 등) 간의 협업과 문화적 변화, 그리고 소프트웨어 제공 프로세스 자동화에 중점을 둔다.[22][23][24]
지속적 배포와 데브옵스는 의미가 비슷하여 혼동되는 경우가 많지만, 서로 다른 개념이다.[32] 데브옵스는 더 넓은 범위를 가지며,[33] 소프트웨어 배포와 관련된 다양한 팀 간의 연계와 소프트웨어 배포 프로세스의 자동화 등 문화적 변화를 중심으로 한다. 반면, 지속적 배포는 배포 자동화에 대한 접근 방식으로, 서로 다른 프로세스를 통합하여 더 빠르고 빈번하게 실행하는 데 중점을 둔다.[34] 이처럼 데브옵스는 지속적 배포의 산물이며, 지속적 배포(CD)는 데브옵스로 직접 이어진다.
7. 구현 및 활용 사례
제즈 험블과 데이비드 파얼리(2010)가 저술한 책은 지속적 배포(CD) 용어를 대중화시켰다. 그러나 이 용어의 정의는 계속 발전해 왔으며, 현재는 더 발전된 의미를 지닌다.[18] 오늘날 여러 기업들이 지속적 배포의 원칙과 모범 사례를 구현하고 있다. 의료 및 웹 분야와 같은 도메인 간의 차이는 여전히 상당하며, 이는 구현 및 사용에 영향을 미친다.[18] 이러한 접근 방식을 사용하는 잘 알려진 회사로는 야후![13], 아마존[14], 페이스북[15], 구글[16], 패디 파워[1], 웰스 파고[17] 등이 있다.
8. 이점 및 과제
마이크로서비스는 지속적 배포를 위한 아키텍처 설계 시 자주 사용된다.[12] 마이크로서비스를 사용하면 소프트웨어 시스템의 배포 가능성과 수정 용이성을 높일 수 있다. 배포 가능성 개선으로는 배포 독립성, 짧은 배포 시간, 단순한 배포 절차, 무중단 배포 등이 있다. 수정 용이성 개선으로는 작고 점진적인 기능 변경에 대한 짧은 사이클 시간, 쉬운 기술 선택 변경, 점진적인 품질 속성 변경, 쉬운 언어 및 라이브러리 업그레이드 등이 있다.[12]
지속적 전달은 디플로이 파이프라인을 통해 가능해진다. 디플로이 파이프라인의 목적은 가시성, 피드백, 지속적인 디플로이로 구성된다.[31]
- '''가시성''': 전달 시스템의 모든 측면(빌드, 디플로이, 테스트, 릴리스)이 팀 내 모든 구성원에게 보여 협업을 촉진한다.
- '''피드백''': 팀 구성원들이 가능한 한 빨리 문제를 인지하고 해결할 수 있도록 돕는다.
- '''지속적인 디플로이''': 완전 자동화된 프로세스를 통해 소프트웨어의 모든 버전을 모든 환경에 릴리스할 수 있다.
지속적 딜리버리는 수동 릴리스를 통해 언제든지 배포할 수 있는 소프트웨어를 제공하는 능력으로, 자동 배포를 사용하는 지속적 배포와는 다르다.[35] 마틴 파울러에 따르면, 지속적 배포에는 지속적 딜리버리가 필요하다.[36] 학술 문헌에서는 수동 및 자동 배포 방법을 통해 이 두 가지 접근 방식을 구별한다.[30][37]
8. 1. 이점
지속적 배포에는 다음과 같은 여러 이점이 보고되었다.[1][18]- 시장 출시 시간 단축: 지속적 배포를 통해 조직은 새로운 소프트웨어 릴리스에 내재된 비즈니스 가치를 고객에게 더 빠르게 제공할 수 있다. 이를 통해 회사는 경쟁에서 한 발 앞서 나갈 수 있다.
- 올바른 제품 구축: 잦은 릴리스를 통해 애플리케이션 개발 팀은 사용자 피드백을 더 빠르게 얻을 수 있다. 이를 통해 유용한 기능만 작업할 수 있으며, 기능이 유용하지 않다고 판단되면 더 이상 노력을 기울이지 않는다. 이는 올바른 제품을 구축하는 데 도움이 된다.
- 향상된 생산성 및 효율성: 자동화를 통해 개발자, 테스터, 운영 엔지니어 등의 시간을 상당히 절약할 수 있다.
- 안정적인 릴리스: 릴리스와 관련된 위험이 현저히 감소하고 릴리스 프로세스가 더욱 안정적으로 되었다. 지속적 배포를 통해 배포 프로세스 및 스크립트는 프로덕션 배포 전에 반복적으로 테스트되므로, 대부분의 오류가 이미 발견된다. 또한 릴리스 빈도가 높아짐에 따라 각 릴리스의 코드 변경 횟수가 줄어들어, 문제 발생 시 더 쉽게 찾고 수정하여 문제의 영향 시간을 줄일 수 있다.
- 향상된 제품 품질: 발견되지 않은 버그 및 프로덕션 사고의 수가 현저히 감소했다.
- 향상된 고객 만족도: 더 높은 수준의 고객 만족도를 달성할 수 있다.
8. 2. 극복해야 할 과제
지속적 배포를 효과적으로 수행하려면 소프트웨어 애플리케이션이 배포 가능성, 수정 용이성, 테스트 용이성과 같은 아키텍처적으로 중요한 요구사항(ASR)을 충족해야 한다.[11] 이러한 요구사항들은 우선순위가 높으며 쉽게 타협할 수 없다.지속적 배포 채택 시 다음과 같은 어려움들이 존재한다.[18]
- 고객 선호도: 일부 고객은 시스템의 빈번한 업데이트를 원하지 않는다. 특히 안정성이 중요한 시스템의 경우 더욱 그렇다.
- 도메인 제약: 통신, 의료, 항공 전자, 철도 및 중공업과 같은 특정 분야에서는 규정상 고객 측 또는 현장 테스트가 필수적이다. 이러한 규제는 지속적 배포의 빠른 배포 주기를 어렵게 만든다.
- 테스트 자동화 부족: 테스트 자동화가 충분히 이루어지지 않으면 개발자들이 지속적 배포에 대한 확신을 갖기 어렵다. 이는 지속적 배포 도입의 큰 걸림돌이 된다.
- 환경 차이: 개발, 테스트, 프로덕션 환경이 서로 다르면, 개발 및 테스트 단계에서 발견되지 않은 문제가 프로덕션 환경에서 발생할 수 있다.
- 인간 테스트 오라클이 필요한 테스트: 사용성, 디자인 등과 같이 자동화된 테스트로 확인하기 어려운 품질 속성들이 존재한다. 이러한 속성들은 사람의 판단을 필요로 하므로, 지속적 배포 파이프라인의 속도를 늦춘다.
첸(Chen)은 조직 구조, 프로세스, 도구, 인프라, 레거시 시스템, 지속적 배포를 위한 아키텍처, 비기능적 요구 사항의 지속적 테스트 및 테스트 실행 최적화 영역에서 8가지 추가적인 채택 과제를 제시했다.[25]
9. 채택 전략
지속적 배포 채택의 어려움을 극복하기 위한 몇 가지 전략이 보고되었다.[25]
| 전략 | 설명 |
|---|---|
| CD를 진통제로 판매하기 | CD가 해결할 수 있는 각 이해 관계자의 문제점을 파악하고, 해당 이해 관계자에게 CD를 진통제로 판매한다. 이 전략은 CD 구현에 필요한 광범위한 이해 관계자로부터 동의를 얻는 데 도움이 된다. |
| 다분야 구성원을 갖춘 전담 팀 | 전담 팀이 없으면, 직원들이 다른 가치 흐름에 배정되는 경우가 많아 진행이 어려울 수 있다. 다분야 팀은 CD 구현에 필요한 광범위한 기술을 제공할 뿐만 아니라 관련 팀과의 의사 소통을 원활하게 한다. |
| 지속적 배포의 지속적 배포 | 가능한 한 빨리 회사에 가치를 제공하는 방식으로 CD 구현을 구성하고, 더 많은 프로젝트를 점진적으로, 소규모로 온보딩하고, 궁극적으로 전체 조직에 CD를 배포한다. 이 전략은 그 과정에서 가시적인 이점을 보여줌으로써 필요한 투자를 정당화하는 데 도움이 된다. 가시적인 이점은 다시 CD로 가는 길고 힘든 여정에서 살아남는 데 필요한 지속적인 회사의 지원과 투자를 얻는 데 도움이 된다. |
| 쉽지만 중요한 애플리케이션부터 시작 | CD로 마이그레이션할 첫 번째 몇 개의 애플리케이션을 선택할 때, 마이그레이션하기는 쉽지만 비즈니스에 중요한 애플리케이션을 선택한다. 마이그레이션이 쉬우면 CD의 이점을 신속하게 보여주는 데 도움이 되므로 구현 계획이 중단되는 것을 방지할 수 있다. 비즈니스에 중요하다는 것은 필요한 자원을 확보하고, 명확하고 반박할 수 없는 가치를 보여주며, 조직 내에서 CD의 가시성을 높이는 데 도움이 된다. |
| 시각적 CD 파이프라인 골격 | 팀에 전체 CD 파이프라인 보기가 있지만 아직 구현할 수 없는 단계에 대해서는 비어 있는 시각적 CD 파이프라인 골격을 제공한다. 이는 CD 마인드를 구축하고 CD 채택의 추진력을 유지하는 데 도움이 된다. 파이프라인 골격은 팀의 CD로의 마이그레이션에 상당한 노력과 오랜 기간의 사고 방식 변화가 필요한 경우에 특히 유용하다. |
| 전문가 투입 | CD 전문가를 개발 팀의 선임 구성원으로 어려운 프로젝트에 투입한다. 팀에 전문가가 있으면 팀 내부에서 CD로 이동하려는 동기와 추진력을 구축하는 데 도움이 된다. 또한 마이그레이션에 많은 노력과 오랜 시간이 필요한 경우에도 추진력을 유지하는 데 도움이 된다. |
10. 클라우드 시스템을 위한 모범 사례
다음은 특히 클라우드 컴퓨팅 환경에서 호스팅되는 시스템의 파이프라인 생산성을 향상시킬 수 있는 몇 가지 방법이다.[19][20][21]
참조
[1]
논문
Continuous Delivery: Huge Benefits, but Challenges Too
https://www.research[...]
[2]
논문
Continuous Integration, Delivery and Deployment: A Systematic Review on Approaches, Tools, Challenges and Practices
[3]
서적
Building Evolutionary Architectures: Automated Software Governance
[4]
서적
Agile 2006 (Agile'06)
[5]
간행물
Continuous Software Engineering and Beyond: Trends and Challenges
http://staff.lero.ie[...]
Association for Computing Machinery
2014-06-03
[6]
웹사이트
Continuous Deployment with MongoDB at Kitchensurfing
http://www.slideshar[...]
2014-01-03
[7]
논문
Continuous Delivery: Patterns and Anti-Patterns in Software Lifecycle
http://www.dccia.ua.[...]
2015-10-09
[8]
서적
Serverless Architectures on AWS
Manning
[9]
논문
The Continuous Delivery Pipeline – What it is and Why it's so important in Developing Software
http://devops.com/20[...]
2015-10-09
[10]
논문
Continuous Delivery: The Agile SUccessor
http://www.drdobbs.c[...]
UBM
2014-09-16
[11]
간행물
Towards Architecting for Continuous Delivery
IEEE
[12]
간행물
Microservices: Architecting for Continuous Delivery and DevOps
https://www.research[...]
IEEE
2018
[13]
웹사이트
Implementing Continuous Delivery at Yahoo!
http://confreaks.tv/[...]
2013-10-23
[14]
웹사이트
Velocity 2011: Jon Jenkins, "Velocity Culture"
https://www.youtube.[...]
2011-06-20
[15]
웹사이트
Rapid Release At Massive Scale
https://code.faceboo[...]
2017-08-31
[16]
웹사이트
The Case for Continuous Delivery
http://www.thoughtwo[...]
2014-07-16
[17]
웹사이트
2014-year-continuous-integration-revolution
http://www.jfrog.com[...]
2014-12
[18]
논문
The Highways and Country Roads to Continuous Deployment
2015-03-01
[19]
서적
Serverless Architectures on AWS
Manning
2022-03-29
[20]
서적
Pipeline as Code Continuous Delivery with Jenkins, Kubernetes, and Terraform
Manning
[21]
서적
Continuous Delivery Reliable Software Releases Through Build, Test, and Deployment Automation
Pearson Education
2010-07-27
[22]
서적
Continuous Delivery: reliable software releases through build, test, and deployment automation
Pearson Education Inc.
2011
[23]
논문
The Relationship between DevOps and Continuous Delivery
http://blogs.forrest[...]
Forester
2011-09-09
[24]
서적
Continuous Delivery and DevOps: A Quickstart guide
Packt Publishing
2012
[25]
논문
Continuous Delivery: Overcoming adoption challenges
[26]
웹사이트
Continuous Deployment: An Essential Guide
https://www.ibm.com/[...]
IBM
2022-11-28
[27]
간행물
2017 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)
https://pure.itu.dk/[...]
[28]
웹사이트
Building Evolutionary Architecture
https://www.thoughtw[...]
[29]
논문
Continuous Delivery: Huge Benefits, but Challenges Too
[30]
논문
Continuous Integration, Delivery and Deployment: A Systematic Review on Approaches, Tools, Challenges and Practices
[31]
논문
Continuous Delivery: Patterns and Anti-Patterns in Software Lifecycle
http://www.dccia.ua.[...]
2015-10-09
[32]
논문
The Relationship between DevOps and Continuous Delivery
http://blogs.forrest[...]
Forester
2011-09-09
[33]
서적
Continuous Delivery: reliable software releases through build, test, and deployment automation
Pearson Education Inc.
2011
[34]
서적
Continuous Delivery and DevOps: A Quickstart guide
Packt Publishing
2012
[35]
논문
Continuous Delivery: Overcoming adoption challenges
[36]
웹사이트
bliki: ContinuousDelivery
http://martinfowler.[...]
2015-10-29
[37]
서적
2017 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)
[38]
저널
Continuous Delivery: Huge Benefits, but Challenges Too
http://ieeexplore.ie[...]
[39]
저널
Continuous Integration, Delivery and Deployment: A Systematic Review on Approaches, Tools, Challenges and Practices
http://arxiv.org/abs[...]
[40]
저널
Continuous Delivery: Overcoming adoption challenges
https://www.scienced[...]
2017-06-01
[41]
웹인용
What Is Continuous Deployment? {{!}} IBM
https://www.ibm.com/[...]
2024-06-16
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com