DevOps 텍스트 교육

DevOps 지속적 제공 및 배포 파이프라인을 어떻게 설계해야 하나요?

여러분의 조직을 포함해 많은 조직에서 개발자는 서로 다른 코드 브랜치에서 독립적으로 코딩합니다. 이 방식은 개별 개발자의 생산성을 높이는 것처럼 보이지만 팀 생산성을 해칩니다.

브랜치를 분리하면 여러 개발자의 코드를 병합하기 어렵습니다. 여러 코드 조각을 통합해 함께 작동하게 하고 고객에게 기능과 혜택을 제공하려면, 대개 여러 개발자의 참여와 상당한 재작업, 오래전에 해결했어야 할 충돌의 해결이 필요합니다.

지속적으로 통합하지 않으면 문제가 더 커집니다

역설적이게도 코드를 병합하는 일이 빌드 주기에서 어렵고 피곤하므로, 대다수 개발팀은 통합 테스트 또는 사용자 인수 테스트 담당자에게 애플리케이션을 넘기기 직전에야 코드를 병합합니다. 이 때문에 문제가 더 커집니다. 공동 작업의 통합 성공과 품질을 품질 보증 팀에만 맡깁니다. 황당한 일이지만, 프로젝트가 지연되고 예산 적자가 급증하며, 사기와 동기가 떨어지고 조직 목표와 약속을 못 지키는 이유를 잘 설명합니다. 전 세계 기업이 예산과 일정에 없던 IT 업무에 매년 약 6,000억 USD를 낭비하는 이유도 설명합니다. IT 재작업이나 임시방편에 쓰는 비용이라고 할 수 있습니다…

트렁크(주 코드 브랜치) 기반 개발이 어떻게 도움이 되나요?

해결책은 트렁크(주 코드 브랜치) 기반 개발과 지속적 통합 및 테스트 자동화를 결합하는 것입니다. 트렁크 기반 개발은 소스 코드 버전 관리의 브랜치 모델로, 개발자가 ‘트렁크’라는 단일 브랜치에서 공동으로 코드를 작업합니다. 장기간 유지되는 다른 개발 브랜치를 만들라는 압력에는 저항합니다.

트렁크 기반 개발은 지속적 통합과 그에 따른 지속적 제공을 실현하는 핵심입니다. 개발자가 하루에 여러 번 변경사항을 트렁크에 커밋하면, 모든 팀원이 최소 24시간마다 한 번은 트렁크에 커밋해야 한다는 지속적 통합의 핵심 요건을 충족하기 쉬워집니다. 코드베이스를 필요할 때 언제나 릴리스할 수 있게 하며, 지속적 제공을 실현하는 데 도움이 됩니다.

지속적 통합으로 배포 가능한 코드를 더 작은 단위로 제공할 수 있습니다

개발자가 자주 체크인하면 더 작은 배치로 개발하고 제공할 수 있어 품질이 높아지고 문제와 충돌을 해결하기 쉬워집니다. 일일 체크인을 통한 지속적 통합은 지속적 통합 및 지속적 제공 프레임워크의 무결성을 지키면서도, 배포할 수 있고 의미 있는 코드를 작게 나누어 만들도록 팀에 동기를 줍니다. 공통 소스 코드 저장소의 업데이트는 팀원이 신속히 조율하고 결정하며 피드백을 나눌 통로가 됩니다.

코드를 체크인할 때마다 지속적 통합 프레임워크가 변경된 모듈에 의존하거나 그 영향을 받는 기능의 자동화된 테스트 케이스를 실행합니다. 무언가 망가지면 해당 체크인을 한 사람이 수정할 책임을 맡습니다. 최우선 과제입니다. 나머지 팀이 트렁크에 작업을 계속 통합하려면 이보다 중요한 일이 없습니다. 트렁크의 안정성과 신뢰성을 지키기 위해 문제가 있는 체크인을 빠르게 수정하거나 롤백할 때까지 해당 모듈의 다른 체크인은 허용하지 않습니다.

이 DevOps 원칙에 동의하지 않는다면 다음 질문에 답해 보세요. 이미 오류가 있는 모듈에 왜 다른 새 코드를 추가하려고 하나요?

타당한 이유가 있을 수 있지만 기술 부채와, 임시방편 위에 또 임시방편을 쌓는 일은 피해야 합니다.

트렁크 기반 개발에 안전망을 더하는 게이트 커밋

DevOps 팀은 게이트 커밋으로 품질을 더 높이고 트렁크에 안전망을 한 겹 더 추가할 수도 있습니다.

개발자가 코드를 체크인하려고 할 때마다 먼저 자동화된 테스트를 실행해 코드를 검증합니다. 검증에 성공한 후에만 정식으로 트렁크에 체크인합니다.

소프트웨어 엔지니어링 가치 흐름의 모든 단계에서 프로덕션과 유사한 환경 사용하기

많은 IT 조직의 또 다른 일반적인 과제는 프로덕션과 사전 프로덕션(개발, 통합, 테스트) 환경이 일치하지 않는 것입니다. 운영체제, 데이터베이스, 타사 도구와 API의 구성, 버전 및 패치 수준이 다르거나, 자체 코드의 여러 버전이 여러 프로덕션 및 사전 프로덕션 환경에 흩어져 있을 수 있습니다. 사전 프로덕션과 프로덕션의 JVM 버전이 아주 조금 달라도 전체 프로덕션 배포의 성패를 좌우할 수 있습니다. 환경을 완전히 통제하고 안에 무엇이 있는지 알지 못하면 어떤 결과를 얻을지 알 수 없습니다.

환경 관리를 일상적인 소프트웨어 개발 및 제공 업무에 포함하기

따라서 사전 프로덕션 시스템은 당연히 프로덕션 시스템의 복제본이어야 합니다. 팀이 프로덕션과 유사한 환경에서 일상 엔지니어링 작업을 안전하게 할 수 있도록, 필요할 때 자동으로 셀프서비스 환경을 만들 수 있게 해야 합니다.

조직의 IT 가치 흐름은 소프트웨어 코드뿐 아니라 코드가 실행되는 환경을 통해서도 가치를 제공합니다. 개발 및 운영 전문가 모두 IT 가치 흐름이 똑같이 중요한 두 가지 요소로 이루어진다는 점을 받아들여야 합니다.

1. 내부 및/또는 외부 고객에게 가치를 제공하는 소프트웨어를 빌드하는 코드.
2. 소프트웨어를 호스팅할 사전 프로덕션 및 프로덕션 환경을 구축하는 코드.

단일 진실 공급원(트렁크)으로 소프트웨어와 환경 관리하기
(코드형 인프라(IaC) 도입이라고도 합니다)

DevOps에서는 사전 프로덕션과 프로덕션 환경을 구축하는 작업도 트렁크의 일부입니다. 이것이 코드형 인프라(IaC)의 가장 명확한 정의입니다. 환경에 호스팅될 소프트웨어를 거의 모르는 고립된 운영팀이 맡는 대신, 개발과 운영 전문가가 함께 코드형 인프라를 구축합니다.

소프트웨어 코드와 환경 코드를 똑같이 중요하게 다루도록 단일 진실 공급원(트렁크)에 두 코드를 모두 저장합니다.

사전 프로덕션과 프로덕션 시스템 전체, 그리고 지속적 통합 및 제공 프레임워크를 포함한 배포 파이프라인을 구축하려면, 버전 관리 시스템에 소프트웨어 코드뿐 아니라 구성, 스크립트와 엔드투엔드 제공 체계에 필요한 모든 것을 저장해야 합니다. 환경의 구성 설정을 영구적으로 바꾸려면 환경 구축 스크립트에서 변경합니다. 다음에 팀원이 환경을 만들 때 처음부터 다시 할 필요가 없습니다.

자세한 문서는 대부분 매우 빨리 쓸모없어지므로 환경 구축 스크립트를 최신 상태로 유지하는 데 힘을 쓰는 것이 더 나은 투자입니다. 셀프서비스 방식으로 필요할 때 환경을 만들 수 없다면, 클라우드 인프라는 제대로 활용하지 못하는 또 하나의 호스팅 플랫폼이 되고 DevOps 추진도 제대로 활용하지 못하는 또 하나의 프로세스 개선 시도에 그치기 때문입니다. 버전 관리 시스템으로 프로덕션 및 사전 프로덕션 환경 전체를 만들 수 있어야 합니다. DevOps에서는 환경을 고치는 것보다 다시 만드는 편이 쉽고 빠릅니다. 수동 변경은 더 이상 허용되지 않습니다. 코드와 구성으로만 환경을 다시 구축하고 구성하고 시작해야 합니다.

새로운 완료 정의(DoD)

지속적 제공 프레임워크와 배포 파이프라인이 정상 가동되면, 새로운 ‘완료 정의(DoD)’가 필요합니다.

관련 고객 기능과 혜택이 다음 조건을 충족할 때 작업을 ‘완료’로 분류합니다.

• 트렁크에서 자동으로 또는 클릭 한 번으로 생성되었습니다.
• 프로덕션과 유사한 환경에서 자동화된 테스트를 거쳤습니다.
• 프로덕션과 유사한 환경에서 시연했습니다.
• 배포할 준비가 되었거나, 더 좋게는 가동 중인 프로덕션 환경에 자동으로 또는 클릭 한 번으로 이미 배포했습니다.

결론

DevOps에서는 프로젝트가 끝날 때가 아니라 일상 업무에서 코드를 통합합니다. 개발자, 운영팀, 정보 보안 전문가는 엔지니어링 수명 주기에 걸쳐 작업의 배포를 수없이 리허설합니다. 실제 배포가 원활히 이루어질 가능성이 높아집니다.

지속적 통합을 도입하면 비즈니스 처리량과 소프트웨어 및 환경의 안정성, 직무 만족도가 높아지고 내부 및 외부 고객이 받는 서비스 품질도 개선됩니다.