DevOps LEGO: 파이프라인을 큐브에 배치하는 방법

우리는 한 시설에서 고객에게 전자 문서 관리 시스템을 제공한 적이 있습니다. 그런 다음 다른 개체로 이동합니다. 그리고 하나 더. 그리고 네 번째에도, 다섯 번째에도. 우리는 너무 열중해서 10개의 분산 개체에 도달했습니다. 그것은 강력하게 드러났습니다... 특히 변경 사항을 전달하게 되었을 때 더욱 그렇습니다. 생산 회로로의 전달 과정에서 테스트 시스템의 5가지 시나리오에는 궁극적으로 10시간과 6-7명의 직원이 필요했습니다. 이러한 비용으로 인해 우리는 가능한 한 드물게 배송을 해야 했습니다. XNUMX년의 운영 끝에 우리는 참을 수 없었고 DevOps를 약간 추가하여 프로젝트를 강화하기로 결정했습니다.

이제 모든 테스트는 3시간 안에 이루어지며 엔지니어 3명과 테스터 XNUMX명 등 XNUMX명이 참여합니다. 개선 사항은 숫자로 명확하게 표현되며 많은 사랑을 받는 TTM의 감소로 이어집니다. 우리의 경험에 따르면 DevOps에 대해 알고 있는 고객보다 DevOps의 혜택을 누릴 수 있는 고객이 더 많습니다. 따라서 DevOps를 사람들에게 더 가깝게 만들기 위해 우리는 간단한 생성자를 개발했으며, 이 게시물에서 이에 대해 더 자세히 설명하겠습니다.

이제 좀 더 자세히 말씀드리겠습니다. 한 에너지 회사는 10개의 대규모 시설에 기술 문서 관리 시스템을 배포하고 있습니다. DevOps 없이 이 정도 규모의 프로젝트를 탐색하는 것은 쉽지 않습니다. 왜냐하면 수동 작업의 상당 부분이 작업을 크게 지연시키고 품질도 저하시키기 때문입니다. 모든 수동 작업에는 오류가 가득합니다. 반면에 설치는 하나만 있지만 모든 것이 자동으로 지속적으로 실패 없이 작동해야 하는 프로젝트가 있습니다. 예를 들어 대규모 모놀리식 조직의 동일한 문서 흐름 시스템이 있습니다. 그렇지 않으면 누군가 수동으로 설정을 지정하고 배포 지침을 잊어버리게 됩니다. 결과적으로 프로덕션에서는 설정이 손실되고 모든 것이 붕괴됩니다.

일반적으로 우리는 계약을 통해 고객과 협력하며, 이 경우 우리의 이해관계가 약간 다릅니다. 고객은 예산과 기술 사양 내에서 엄격하게 프로젝트를 검토합니다. 기술 사양에 포함되지 않은 다양한 DevOps 방식의 이점을 그에게 설명하는 것은 어려울 수 있습니다. 비즈니스 가치가 추가된 빠른 릴리스나 자동화 파이프라인 구축에 관심이 있다면 어떻게 될까요?

아쉽게도 사전 승인된 비용으로 작업할 때 이러한 관심이 항상 발견되는 것은 아닙니다. 우리 실무에서는 부도덕하고 부주의한 계약자의 개발을 맡아야 하는 경우가 있었습니다. 끔찍했습니다. 최신 소스 코드가 없었고, 동일한 시스템의 코드 베이스가 설치마다 달랐으며, 문서가 부분적으로 없었고 부분적으로 품질이 형편없었습니다. 물론 고객은 소스 코드, 어셈블리, 릴리스 등에 대한 통제권을 갖지 못했습니다.

지금까지 DevOps에 대해 모든 사람이 아는 것은 아니지만 DevOps의 장점, 실제 리소스 절약에 대해 이야기하자마자 모든 고객의 눈이 밝아집니다. 따라서 DevOps를 포함하는 요청 수가 시간이 지남에 따라 증가하고 있습니다. 여기서 고객과 동일한 언어로 쉽게 대화하려면 적절한 개발 파이프라인을 구축하는 데 도움이 되는 비즈니스 문제와 DevOps 관행을 신속하게 연결해야 합니다.

따라서 한편으로는 일련의 문제가 있고 다른 한편으로는 DevOps 지식, 관행 및 도구가 있습니다. 모든 사람과 경험을 공유해 보는 것은 어떨까요?

DevOps 생성자 만들기

Agile에는 자체 선언문이 있습니다. ITIL에는 자체 방법론이 있습니다. DevOps는 운이 좋지 않습니다. 아직 템플릿과 표준을 획득하지 못했습니다. 하지만 일부 노력하다 개발 및 운영 관행에 대한 평가를 기반으로 기업의 성숙도를 결정합니다.

다행히 2014년에 잘 알려진 기업인 Gartner가 소브랄라 주요 DevOps 관행과 이들 간의 관계를 분석했습니다. 이를 바탕으로 다음과 같은 인포그래픽을 공개했습니다.

우리는 그것을 우리의 기초로 삼았습니다. 생성자. 네 가지 영역 각각에는 일련의 도구가 있습니다. 이를 데이터베이스에 수집하고 가장 인기 있는 항목을 식별하고 통합 지점과 적합한 최적화 메커니즘을 식별했습니다. 전체적으로 밝혀졌습니다 36가지 관행과 115가지 도구, 그 중 XNUMX분의 XNUMX은 오픈 소스 또는 무료 소프트웨어입니다. 다음으로, 각 영역에서 우리가 달성한 성과에 대해 이야기하고, 예를 들어 우리가 게시물을 시작한 기술 문서 관리 생성 프로젝트에서 이것이 어떻게 구현되었는지에 대해 이야기하겠습니다.

프로세스

악명 높은 EDMS 프로젝트에서는 기술 문서 관리 시스템이 10개 개체 각각에 동일한 체계에 따라 배포되었습니다. 설치에는 데이터베이스 서버, 애플리케이션 서버, 전체 텍스트 인덱싱 및 콘텐츠 관리 등 4개의 서버가 포함됩니다. 설치 시 단일 노드 내에서 작동하며 시설의 데이터 센터에 위치합니다. 모든 개체는 인프라가 약간 다르지만 이것이 글로벌 상호 작용을 방해하지는 않습니다.

먼저 DevOps 관행에 따라 인프라를 로컬로 자동화한 다음 테스트 회로로 전달한 다음 고객 제품으로 전달했습니다. 각 프로세스는 단계별로 진행되었습니다. 환경 설정은 자동 업데이트를 위해 컴파일된 배포 키트를 고려하여 소스 코드 시스템에서 수정됩니다. 구성이 변경되는 경우 엔지니어는 버전 제어 시스템을 적절하게 변경하기만 하면 문제 없이 자동 업데이트가 이루어집니다.

이 접근 방식 덕분에 테스트 프로세스가 크게 단순화되었습니다. 이전에는 프로젝트에 스탠드를 수동으로 업데이트하는 것 외에는 아무것도 하지 않는 테스터가 있었습니다. 이제 그들은 와서 모든 것이 제대로 작동하는지 확인하고 더 유용한 일을 합니다. 각 업데이트는 표면 수준에서 비즈니스 시나리오 자동화에 이르기까지 자동으로 테스트됩니다. 결과는 TestRail에 별도의 보고서로 게시됩니다.

문화

지속적인 실험은 테스트 설계의 예를 통해 가장 잘 설명됩니다. 아직 존재하지 않는 시스템을 테스트하는 것은 창의적인 작업입니다. 테스트 계획을 작성할 때 올바르게 테스트하는 방법과 따라야 할 분기를 이해해야 합니다. 또한 최적의 검사 횟수를 결정하기 위해 시간과 예산 사이의 균형을 찾으세요. 필요한 테스트를 정확하게 선택하고, 사용자가 시스템과 상호 작용하는 방법을 생각하고, 환경 및 가능한 외부 요인을 고려하는 것이 중요합니다. 끊임없는 실험 없이는 불가능합니다.

이제 상호 작용의 문화에 대해 알아보십시오. 이전에는 엔지니어와 개발자라는 두 가지 반대 측면이 있었습니다. 개발자들은 이렇게 말했습니다. “우리는 그것이 어떻게 출시될지는 상관하지 않습니다. 당신은 엔지니어이고 똑똑합니다. 오류 없이 작동하는지 확인하세요.". 엔지니어들은 이렇게 대답했습니다. “당신들 개발자들은 너무 부주의해요. 좀 더 주의를 기울이면 귀하의 릴리스를 덜 자주 재생하겠습니다. 누출된 코드를 제공할 때마다 상호 작용 방법이 명확하지 않기 때문입니다.”. 이는 DevOps 관점과 다르게 구조화된 문화적 상호 작용 문제입니다. 여기에서는 엔지니어와 개발자 모두 끊임없이 변화하는 동시에 안정적인 소프트웨어에 초점을 맞춘 단일 팀의 일원입니다.

같은 팀 내에서 전문가들은 서로를 돕기로 결심했습니다. 예전처럼요? 예를 들어, 50페이지 정도 되는 두꺼운 배포 지침을 준비 중인데 엔지니어가 그것을 읽고 뭔가 이해하지 못하고 욕을 하며 새벽 XNUMX시에 개발자에게 코멘트를 요청했습니다. 개발자는 댓글을 달고 저주도 했습니다. 결국 아무도 행복하지 않았습니다. 게다가 당연히 지침의 모든 내용을 기억할 수 없기 때문에 몇 가지 실수가 있었습니다. 이제 엔지니어는 개발자와 함께 애플리케이션 소프트웨어 인프라의 자동화된 배포를 위한 스크립트를 작성하고 있습니다. 그리고 그들은 실제로 같은 언어로 서로 이야기합니다.

사람들

팀 규모는 업데이트 범위에 따라 결정됩니다. 팀은 납품 구성 중에 모집되며, 여기에는 일반 프로젝트 팀의 관심 있는 사람들이 포함됩니다. 그런 다음 각 단계의 담당자와 함께 업데이트 계획을 작성하고 팀에서는 진행 상황을 보고합니다. 모든 팀원은 교체 가능합니다. 팀의 일원으로 백업 개발자도 있지만 그는 연결할 필요가 거의 없습니다.

기술

기술 다이어그램에는 몇 가지 사항이 강조되어 있지만 그 아래에는 많은 기술이 있습니다. 해당 설명이 포함된 전체 책을 출판할 수 있습니다. 그래서 우리는 가장 흥미로운 것을 강조하겠습니다.

코드로서의 인프라

이제 아마도 이 개념은 누구에게도 놀라지 않을 것입니다. 그러나 이전에는 인프라에 대한 설명이 많이 필요했습니다. 엔지니어들은 공포에 질려 지침을 살펴보았습니다., 테스트 환경은 독특하고 소중하고 소중하며 먼지 입자가 날아갔습니다.

요즘에는 누구도 실험을 두려워하지 않습니다. 가상 머신의 기본 이미지가 있고 환경 배포를 위해 미리 만들어진 시나리오가 있습니다. 모든 템플릿과 스크립트는 버전 제어 시스템에 저장되며 즉시 업데이트됩니다. 이전에는 패키지를 스탠드에 전달해야 할 때 구성 차이가 나타났습니다. 이제 소스 코드에 한 줄만 추가하면 됩니다.

인프라 스크립트 및 파이프라인 외에도 코드형 문서 접근 방식도 문서화에 사용됩니다. 덕분에 새로운 사람들을 프로젝트에 쉽게 연결하고, 테스트 계획 등에 설명된 기능을 기반으로 시스템에 소개하고, 테스트 사례를 재사용하는 것도 쉽습니다.

지속적인 전달 및 모니터링

마지막 기사에서 DevOps에 관해 우리는 지속적인 제공 및 모니터링을 구현하기 위한 도구를 어떻게 선택했는지에 대해 이야기했습니다. 아무것도 다시 작성할 필요가 없는 경우가 많습니다. 이전에 작성된 스크립트를 사용하고, 구성요소 간 통합을 올바르게 구축하고, 공통 관리 콘솔을 생성하는 것만으로도 충분합니다. 그리고 하나의 버튼이나 일정을 사용하여 모든 프로세스를 시작할 수 있습니다.

영어에는 Continuous Delivery와 Continuous Distribution이라는 다양한 개념이 있습니다. 둘 다 '지속적인 전달'로 번역할 수 있지만 실제로는 약간의 차이가 있습니다. 분산 에너지 회사의 기술 문서 흐름을 위한 우리 프로젝트에서는 명령에 따라 생산을 위한 설치가 발생할 때 배송이 사용됩니다. 배포에서는 설치가 자동으로 수행됩니다. 이 프로젝트의 지속적 전달은 일반적으로 DevOps의 핵심 부분.

일반적으로 특정 매개변수를 수집하면 DevOps 방식이 유용한 이유를 명확하게 이해할 수 있습니다. 그리고 숫자를 정말 좋아하는 경영진에게 이를 전달하세요. 총 실행 횟수, 스크립트 단계의 실행 시간, 성공적인 실행 비율 - 이 모든 것은 모든 사람이 선호하는 출시 시간, 즉 버전 제어 시스템 커밋부터 버전 출시까지의 시간에 직접적인 영향을 미칩니다. 생산 환경. 필요한 도구를 구현하면 엔지니어는 우편으로 귀중한 지표를 받게 되며 프로젝트 관리자는 이를 대시보드에서 확인할 수 있습니다. 이렇게 하면 새로운 도구의 이점을 즉시 평가할 수 있습니다. 그리고 DevOps 디자이너를 사용하여 인프라에서 이를 시험해 볼 수 있습니다.

누가 우리를 필요로 할까요? DevOps 디자이너?

가장하지 말자. 우선 그는 우리에게 유용하게 되었다. 이미 말했듯이 고객과 동일한 언어로 대화해야 하며 DevOps 디자이너의 도움으로 그러한 대화의 기초를 빠르게 스케치할 수 있습니다. 비즈니스 전문가는 자신에게 필요한 것이 무엇인지 스스로 평가하여 더 빠르게 개발할 수 있습니다. 우리는 디자이너를 최대한 상세하게 만들고 모든 사용자가 자신이 선택한 것을 이해할 수 있도록 많은 설명을 추가하려고 노력했습니다.

디자이너의 형식을 통해 회사의 기존 건축 프로세스 및 자동화 개발을 고려할 수 있습니다. 기존 프로세스와 잘 통합되고 간단히 공백을 메울 수 있는 솔루션만 선택할 수 있다면 모든 것을 허물고 다시 구축할 필요가 없습니다.

아마도 귀하의 개발이 이미 더 높은 수준으로 이동했으며 우리 도구가 너무 "선장의" 것처럼 보일 것입니다. 그러나 우리는 이것이 우리 자신에게 유용하다고 생각하며 일부 독자들에게도 도움이 되기를 바랍니다. 우리는 당신에게 상기시켜줍니다 링크 디자이너에게 - 초기 데이터를 입력한 후 즉시 다이어그램을 받게 됩니다. 귀하의 피드백과 추가 사항에 감사드립니다.

출처 : habr.com