연속 배송이 끝날 때 수동 단계를 구현하는 방법은 무엇입니까?

" 지속적인 통합이 지속적인 배달 / 배포와 어떤 관련이 있습니까? " 에 대한 나의 질문에 대한 대답 은 지속적인 배달 과 지속적인 배포 의 작은 차이점 도 설명 합니다 . "생산에 어떻게 배치하고 싶은가? 반면에 선택할 수있는 (독점적) 옵션과 같은 질문에 대한 답변과 관련이있는 것 같습니다.

• 자동적 인).
• 설명서.

DevOps 벽의 반대편에는 "수동"이 의미하는 바에 해당하는 무언가를해야하는 가난한 "운영자"가있을 것이라고 상상할 수 없습니다. 내 질문 :

• "배포"와 "설치"에 대한 나의 언급 (내 질문에)이 그러한 "수동"의 구현에 가깝습니까? 내 관련 질문에 대한 관련 인용문은 다음과 같습니다.

• FTP와 같은 것을 사용하여 일부 대상 환경에 배포 하지만 (표준 사본이 간격을 메울 수없는 경우) 대상에서이를 활성화하지 마십시오. 그것이 지속적인 전달 과 비슷하거나 비슷해야하는가?
• 바인드, 중지 / 시작 작업 등과 같은 일부 대상 환경에 설치 (또는 활성화 )합니다. 이것이 지속적인 배포 와 유사하거나 근접해야하는가?

• 다른 가능한 구현은 무엇입니까?

개인적으로 저는 distribution배포의 중간 단계 인 소프트웨어의 대상을 고려 합니다. 배포를 완료하려면 해당 소프트웨어의 설치 / 활성화가 필요합니다.

나받는 사람 delivery(같이 continuos delivery) 소프트웨어가 만들어 배포 할 때 정지 가능 배포 (즉, 배포, 설치 및 활성화를위한)

따라서 첫 번째 질문에 대답하기 위해 아니오, 지속적인 배포와 지속적인 배포를 차별화하는 수동 단계를 반영하는 배포 및 설치를 고려하지 않습니다.

예 (일부 드물게) 수동 단계가 생산에 배치하기위한 최종 인간 결정일 뿐이며, 프로세스 자동화의 문화적 불신과 인간의 이중 점검 및 배치 결정의 정신적 편의성을 반영합니다 (따라서 가정) 그 결정이 순전히 자동화 될 수있는 알고리즘 (카운팅 통과 / 실패 테스트 결과와 같은)을 기반으로 결정된 경우에도 그 책임.

그러나 일반적으로 프로덕션 환경에서 배포를 수행하기로 한 결정이 단순히 자동화 된 알고리즘의 결과가 아니라는 사실을 반영합니다. 다음은 그러한 경우의 예입니다.

• 자동 결정을 덮어 씁니다.
  • 모든 품질 기준을 충족하지 않아도 배포에 서명 할 수 있음
  • 모든 기준이 충족 되더라도 (예 : 시장 타이밍 영향으로 인해) 어떤 이유로 든 배포가 유지됩니다.
• 자동화 알고리즘이 (아직) 구현 / 배포되지 않았습니다.
• 이 알고리즘에는 사람의 결정에 따라 몇 가지 기준에 대한 검사가 포함됩니다 (예 : 수동 테스트 결과)
• 추가 고객 확인 후 실제로 타사 고객 환경에서 배포가 수행됩니다.

따라서 수동 단계를 단순히 구현 문제로 보지 않습니다.

다른 프로젝트에서 소비 할 것으로 예상되는 것을 게시하는 경우 배포시 "다른 사용자가 사용할 수 있도록 게시"라는 의미도 고려해야합니다.

라이브러리를 공통 아티팩트 저장소에 배치하는 워크 플로우를 고려하십시오. 프로세스의이 부분은 빌드시 해당 아티팩트가 필요한 다른 구성 요소를 배치하거나 공통 라이브러리에 대한 갱신일 수 있습니다. 그러나 해당 아티팩트에 관계없이 수명주기는 반드시 다른 사람이 사용할 수있게되어 종료되는 것은 아니지만, 아티팩트 저장소에 해당 아티팩트를 배치하는 것은 개발자가 작업을 중단하기로 결정한 후 최종 단계 일 수 있습니다. 새로운 릴리스 버전과 다른 사람들이 새 버전을 안전하게 사용할 수 있습니다.