하나님은 CI/CD를 사용하십니까?
하나님의 지속적인 통합 및 배포 파이프라인은 어떻게 생겼으며 이것이 우리에게 무엇을 말합니까?

신이 소프트웨어를 개발한다고 상상해보자. 그들은 몇 가지 코드를 작성하고 깨끗한 GIT 저장소에 커밋했습니다. 하나님은 어떤 종류의 CI/CD 파이프라인을 사용하실까요?
하나님은 전지하시고 전능하시며 그 외에는 무오하시다. 하나님은 실수하지 않으십니다. 또는 소프트웨어 개발의 경우 신은 버그를 작성하지 않습니다.
신은 정적 코드 분석을 필요로 합니까? 아니요, 하나님의 코드는 아름답고 형식이 적절하며 모든 스타일 지침과 모범 사례를 완벽하게 준수합니다.
신은 단위 테스트를 필요로 합니까? 글쎄, 우리가 신이 이 코드를 수정하는 유일한 사람이 될 것이라고 가정하고 그들이 작성한 내용을 완벽하게 기억한다고 가정한다면 — 단위 테스트의 문서화 가치를 무시하고 아니요, 신은 단위 테스트가 필요하지 않다고 말할 수 있습니다 .
생산을 위해 준비되기 전에 하나님의 코드가 통과해야 하는 파이프라인의 다른 단계는 무엇입니까? 보안 검사? 자동화된 통합 테스트? 준수 확인? 사용성 테스트?
없음. 하나님의 코드는 마지막 키 입력이 하나님의 키보드를 클릭하는 즉시 생산을 위한 준비가 되어 있습니다. 하나님의 코드는 100% 확신을 가지고 존재를 시작하며, 어떤 영역, 차원, 범위에서 많은 검증이 필요하지 않습니다. 신의 코드는 신성한.
따라서 신은 CI/CD 파이프라인에서 검증이 필요하지 않습니다. 신은 그들의 코드를 커밋하고, 그 코드가 나타내는 어떤 아티팩트든 빌드하고, 그 아티팩트를 생산에 직접적이고 즉시 푸시할 수 있습니다. 하나님의 코드는 개념의 순간부터 생산 준비가 되어 있기 때문에 하나님은 일종의 간단한 빌드-배포 파이프라인만 사용합니다.
이 작은 신성 모독이 CI/CD 파이프라인에 대한 중요한 요점을 전달하는 데 도움이 되기를 바랍니다.
CI/CD 파이프라인의 많은(대부분?) 존재하는 이유는 신과 달리 우리 코드가 의심스럽다. 우리 코드는 검증이 필요하고, 이것 때문에 CI/CD 파이프라인의 핵심이 존재합니다.
인프라 또는 DevOps 설득의 일부는 이 진술에 대해 당황할 수 있습니다. 빌드 타임 구성을 가져오는 것은 어떻습니까? 의존성 관리? 자산 수집 및 유물 배포?
예, 이 모든 것이 '파이프라인'의 일부입니다. 자산을 빌드하고 배포하는 것은 비검증이지만 완벽한 코드를 가정할 수 있다면 빌드-배포 파이프라인은 매우 간단할 것입니다. 최신 CI/CD 파이프라인의 복잡성은 코드에 대한 확신이 없기 때문입니다. 신처럼 완벽한 코드를 구축하고 배포하는 것은 실제로 생성할 수 있는 매우 간단한 유형의 파이프라인이 될 것입니다.
아래는 CI/CD 파이프라인에 대한 유명한 책입니다. 사실 많은 사람들이 그것을 CI/CD의 성경(HA!)이라고 생각합니다. 이 책은 본질적으로 테스트에 관한 책입니다. 의심스럽고 신뢰도가 낮은 코드를 사용하고 프로덕션에 배포할 준비가 될 때까지 가능한 한 효과적이고 효율적으로 필요한 단계를 거쳐 이동하는 기계를 만들고 구성하는 방법에 관한 것입니다.

CI/CD 파이프라인 다이어그램에 대한 Google 이미지 검색을 수행하고 품질 또는 테스트와 관련이 없거나 지원하지 않는 단계를 찾으십시오. 나는 거의 찾지 않았고 결과 페이지 7(내가 거의 가지 않는 곳)에 있습니다.
CI/CD 파이프라인을 코드 검증 프로세스를 지원하고 가능하게 하는 시스템으로 보는 이러한 관점은 의미론적이거나 유휴 사고 실험이 아닙니다. 이는 파이프라인이 검증의 요구와 검증을 수행하는 사람들(개발자, 테스터, 운영)을 지원하도록 구축되어야 한다는 것을 강화합니다. , 등. 이들은 CI/CD 파이프라인의 고객이며 건강한 파이프라인에 대한 지속적인 투자와 유지 관리가 없으면 불가능하지는 않더라도 엄청나게 어려울 것입니다.
실제로 다음과 같이 매우 단순화된 다이어그램에 나와 있는 것처럼 프로덕션 배포 준비가 될 때까지 코드에 대한 확신을 점진적으로 높이는 일련의 단계로 CI/CD 파이프라인을 줄일 수 있습니다.

이것은 매우 품질 중심적인 관점이지만 품질 엔지니어링 이사에게 기대할 수 있는 것이지만, 저는 이것이 가장 잘 설명한다고 생각합니다. 존재 이유 CI/CD의: CI/CD 파이프라인은 유효성 검사를 지원하기 위해 존재하며 다른 모든 것은 필러일 뿐입니다.
소프트웨어를 만드는 우리는 종종 우리 자신을 매우 높이 생각하지만, 우리를 신과 나란히 놓으면 오류 가능성이 명백해지고 테스트와 확인의 필요성이 분명해집니다.
신은 실수로 탭과 공백을 섞거나 잘못된 줄에 대괄호를 여는 것이 아닙니다. 그래서 우리는 린트 및 정적 분석 도구가 필요합니다.
God의 클래스와 함수는 특정 입력 값으로 실패하거나 예기치 않은 예외가 발생하지 않으므로 포괄적인 단위 테스트가 필요합니다.
신은 선형 시간 구현이 가능할 때 지수 알고리즘을 작성하지 않거나 인덱싱되지 않은 열에서 무제한 테이블을 실수로 쿼리하지 않습니다. 우리는 때때로 그렇게 하기 때문에 스트레스, 부하, 흡수, 탄력성 및 기타 유형의 성능 테스트와 이를 수행할 수 있는 환경이 필요합니다.
그분의 수락 기준에 대한 하나님의 해석은 인간 언어의 부정확성과 모호성으로 인해 어려움을 겪지 않습니다. 우리는 이를 검증하기 위해 구성 요소, 통합, 사용자 승인 및 기타 모든 종류의 테스트가 필요하며, 이를 수행하기 위해 배포된 적절한 환경도 필요합니다.
하나님은 그분의 코드가 완벽하기 때문에 프로덕션 환경에서 작동하는지 알려드리기 위해 원격 측정 데이터가 필요하지 않습니다. 우리는 그렇지 않으므로 이러한 데이터 경로와 기능을 테스트하기 위해 시스템과 장소에 관찰 가능성이 구축되어 있어야 합니다.
하나님은 테스트를 실행하지 않고 금요일 오후 5시에 프로덕션에 밀어넣으시고 걱정 없이 건너뛰십니다. 왜냐하면 그분의 코드는 항상 그리고 영원히 완벽하기 때문입니다.
우리의 코드는 의심이 되며, 잘 설계된 CI/CD 파이프라인을 통해 실행될 때까지 가능한 모든 가능한 실패 방식을 검증하는 단계가 있을 때까지 잘못된 것으로 가정해야 합니다.
신은 CI/CD 파이프라인을 사용하지 않습니다. 우리는 반드시 사용해야 합니다.
'Coding' 카테고리의 다른 글
Docker 컨테이너 간에 Postgres 소켓을 공유하는 방법 (0) | 2022.05.09 |
---|---|
C++로 테스트 프레임워크를 구축하기 위한 5가지 필수 매크로 (0) | 2022.05.08 |
Async / Await in Go 사용 방법 (0) | 2022.05.02 |
SwiftUI를 사용한 흐름 탐색(재검토) (0) | 2022.04.29 |
Linux chmod 및 chown – Linux에서 파일 권한 및 소유권을 변경하는 방법 (0) | 2022.04.28 |
댓글