DevOps를 사용하여 본격적인 사내 개발을 구축하는 방법 - VTB 경험

DevOps 관행이 작동합니다. 우리는 릴리즈 설치 시간을 10배 단축하면서 이를 확신했습니다. VTB에서 사용하는 FIS 프로필 시스템에서는 이제 설치에 90분이 아닌 10분이 소요됩니다. 릴리스 빌드 시간이 XNUMX주에서 XNUMX일로 단축되었습니다. 지속적인 구현 결함의 수가 거의 최소 수준으로 떨어졌습니다. '육체 노동'에서 벗어나 공급업체에 대한 의존도를 없애기 위해 우리는 목발을 짚고 일하며 예상치 못한 해결책을 찾아야 했습니다. 컷 아래에는 본격적인 내부 개발을 어떻게 구축했는지에 대한 자세한 이야기가 나와 있습니다.

 

프롤로그: DevOps는 철학입니다

지난 한 해 동안 우리는 VTB에서 DevOps 관행의 내부 개발 및 구현을 조직하기 위해 많은 작업을 수행했습니다.

• 우리는 12개 시스템에 대한 내부 개발 프로세스를 구축했습니다.
• 우리는 15개의 파이프라인을 출시했으며 그 중 XNUMX개는 생산에 들어갔습니다.
• 자동화된 1445 테스트 시나리오;
• 우리는 내부 팀에서 준비한 여러 릴리스를 성공적으로 구현했습니다.

DevSecOps 관행의 내부 개발 및 구현을 구성하기 가장 어려운 것 중 하나는 비관계형 DBMS의 소매 제품 프로세서인 FIS 프로필 시스템으로 밝혀졌습니다. 그럼에도 불구하고 우리는 개발을 구축하고, 파이프라인을 시작하고, 제품에 개별 비릴리스 패키지를 설치하고, 릴리스를 조합하는 방법을 배울 수 있었습니다. 작업은 쉽지 않았지만 흥미롭고 구현에 대한 명확한 제한이 없었습니다. 여기에 시스템이 있습니다. 내부 개발을 구축해야 합니다. 유일한 조건은 생산적인 환경 이전에 CD를 사용하는 것입니다.

처음에는 구현 알고리즘이 간단하고 명확해 보였습니다.

• 우리는 초기 개발 전문 지식을 개발하고 중대한 결함 없이 코드 팀으로부터 허용 가능한 수준의 품질을 달성합니다.
• 우리는 가능한 한 기존 프로세스에 통합합니다.
• 명확한 단계 간에 코드를 전송하기 위해 파이프라인을 자르고 그 끝 중 하나를 연속으로 밀어 넣습니다.

이 기간 동안 필요한 규모의 개발팀은 기술을 개발하고 릴리스에 대한 기여도를 허용 가능한 수준으로 높여야 합니다. 이제 작업이 완료된 것으로 간주할 수 있습니다.

이것은 필요한 결과를 얻기 위한 완전히 에너지 효율적인 경로인 것 같습니다. 여기에 DevOps가 있고, 여기에 팀의 성과 지표가 있으며, 여기에 축적된 전문 지식이 있습니다... 그러나 실제로 우리는 DevOps가 여전히 철학에 관한 것이라는 또 다른 확인을 받았습니다. , "gitlab 프로세스, ansible, nexus 및 목록 아래에 연결되어 있지 않습니다."

실행 계획을 다시 한 번 분석한 결과, 우리는 우리 내부에 일종의 아웃소싱 공급업체를 구축하고 있음을 깨달았습니다. 따라서 위에서 설명한 알고리즘에 프로세스 리엔지니어링을 추가하고 전체 개발 경로에 대한 전문 지식을 개발하여 이 프로세스에서 주도적인 역할을 수행했습니다. 가장 쉬운 선택은 아니지만 이것이 이념적으로 올바른 발전의 길입니다.
 

사내 개발은 어디서 시작되나요? 

작업하기에 가장 친숙한 시스템은 아니었습니다. 구조적으로는 하나의 대규모 비관계형 DBMS였으며 필요에 따라 호출되는 별도의 실행 가능 개체(스크립트, 프로시저, 배치 등)로 구성되었으며 블랙박스 원리에 따라 작동했습니다. 요청을 받고 문제를 발행했습니다. 응답. 주목할만한 다른 어려움은 다음과 같습니다.

• 이국적인 언어(MUMPS);
• 콘솔 인터페이스;
• 널리 사용되는 자동화 도구 및 프레임워크와의 통합 부족
• 수십 테라바이트 단위의 데이터 볼륨
• 시간당 2만 개 이상의 작업 로드
• 중요성 - 비즈니스에 중요함.

동시에 우리 측에는 소스 코드 저장소도 없었습니다. 조금도. 문서가 있었지만 모든 핵심 지식과 역량은 외부 조직 측에 있었습니다.
우리는 시스템의 기능과 낮은 배포를 고려하여 거의 처음부터 시스템 개발을 마스터하기 시작했습니다. 2018년 XNUMX월에 시작됨:

• 코드 생성의 문서화 및 기본 사항을 연구했습니다.
• 우리는 벤더로부터 받은 개발에 관한 단기 과정을 공부했습니다.
• 초기 개발 기술을 습득했습니다.
• 우리는 새로운 팀원을 위한 교육 매뉴얼을 작성했습니다.
• 우리는 팀을 "전투" 모드에 포함시키는 데 동의했습니다.
• 코드 품질 관리 문제를 해결했습니다.
• 우리는 발전을 위한 스탠드를 조직했습니다.

우리는 2019개월 동안 전문 지식을 개발하고 시스템에 몰입했으며, XNUMX년 초부터 사내 개발은 때로는 어려움이 있지만 자신감 있고 의도적으로 밝은 미래를 향한 움직임을 시작했습니다.

저장소 마이그레이션 및 자동 테스트

첫 번째 DevOps 작업은 저장소입니다. 우리는 액세스 제공에 빠르게 동의했지만 여러 브랜치 모델로의 전환과 Git Flow 개발을 통해 하나의 트렁크 브랜치가 있는 현재 SVN에서 대상 Git으로 마이그레이션해야 했습니다. 우리는 또한 자체 인프라를 갖춘 2개의 팀과 해외 공급업체 팀의 일부를 보유하고 있습니다. 저는 두 개의 Git과 함께 생활하면서 동기화를 보장해야 했습니다. 그러한 상황에서 그것은 두 가지 악 중 덜한 것이었습니다.

저장소 마이그레이션은 반복적으로 연기되었으며 일선 동료들의 도움으로 XNUMX월에야 완료되었습니다. Git Flow를 사용하여 우리는 처음부터 일을 단순하게 유지하기로 결정하고 핫픽스, 개발 및 릴리스를 포함하는 고전적인 체계에 정착했습니다. 그들은 마스터(일명 prod-like)를 포기하기로 결정했습니다. 아래에서는 이 옵션이 우리에게 최적인 이유를 설명합니다. 두 팀이 공통으로 사용하는 벤더 소유의 외부 저장소를 작업자로 사용했습니다. 일정에 따라 내부 저장소와 동기화되었습니다. 이제 Git과 Gitlab을 사용하면 프로세스를 자동화하는 것이 가능해졌습니다.

자동 테스트 문제는 놀라울 정도로 쉽게 해결되었습니다. 기성 프레임워크가 제공되었기 때문입니다. 시스템의 특성을 고려하면 별도의 작업을 호출하는 것은 비즈니스 프로세스의 이해 가능한 부분이자 동시에 단위 테스트 역할을 했습니다. 남은 것은 테스트 데이터를 준비하고 스크립트를 호출하고 결과를 평가하는 순서를 원하는 대로 설정하는 것뿐이었습니다. 운영 통계, 프로세스의 중요도, 기존 회귀 방법론을 기반으로 구성된 시나리오 목록이 작성되면서 자동 테스트가 나타나기 시작했습니다. 이제 파이프라인 구축을 시작할 수 있습니다.

어땠나요: 자동화 이전의 모델

구현 프로세스의 기존 모델은 별도의 이야기입니다. 각 수정 사항은 별도의 증분 설치 패키지로 수동으로 전송되었습니다. 다음은 Jira에 수동으로 등록하고 환경에 수동으로 설치하는 것입니다. 개별 패키지의 경우 모든 것이 명확해 보였지만 릴리스를 준비하면서 상황이 더욱 복잡해졌습니다.

조립은 독립된 개체인 개별 배송 수준에서 수행되었습니다. 모든 변경 사항은 새로운 배송입니다. 무엇보다도 주요 릴리스 구성의 60-70개 패키지에 10-15개의 기술 버전이 추가되었습니다. 이는 릴리스에서 무언가를 추가하거나 제외하고 릴리스 외부 판매 변화를 반영하여 얻은 버전입니다.

전달 내의 개체는 서로 겹쳤습니다. 특히 실행 코드의 경우 고유성이 절반도 안 되었습니다. 이미 설치된 코드와 방금 설치가 계획된 코드 모두에 많은 종속성이 있었습니다. 

필요한 코드 버전을 얻으려면 설치 순서를 엄격하게 따라야 했으며, 그 동안 객체는 물리적으로 여러 번(약 10~12회) 다시 작성되었습니다.

패키지 배치를 설치한 후 설정을 초기화하려면 지침을 수동으로 따라야 했습니다. 릴리스는 공급업체에서 조립하고 설치했습니다. 릴리스 구성은 구현 순간 거의 전에 명확해졌으며, 이로 인해 "디커플링" 패키지가 생성되었습니다. 결과적으로 공급품의 상당 부분이 "디커플링"이라는 자체 꼬리와 함께 출시에서 출시로 이동했습니다.

이제 패키지 수준에서 릴리스 퍼즐을 조립하는 이 접근 방식에서는 단일 마스터 브랜치가 실질적인 의미가 없다는 것이 분명해졌습니다. 생산 시 설치에 수작업이 소요되는 시간은 XNUMX시간 XNUMX분에서 XNUMX시간 정도 소요되었습니다. 적어도 설치자 수준에서는 개체 처리 순서가 지정되어 있는 것이 좋습니다. 필드와 구조는 해당 항목과 절차에 대한 데이터보다 먼저 입력되었습니다. 그러나 이는 별도의 패키지 내에서만 작동했습니다.

이 접근 방식의 논리적 결과는 비뚤어진 버전의 객체, 불필요한 코드, 누락된 지침, 객체의 상호 영향에 대한 설명되지 않은 형태의 의무적인 설치 결함이었으며, 이는 출시 후 열광적으로 제거되었습니다. 

첫 번째 업데이트: 조립 및 전달 커밋

자동화는 다음 경로를 따라 파이프를 통해 코드를 전송함으로써 시작되었습니다.

• 완성된 배송물을 창고에서 픽업하세요.
• 전용 환경에 설치하세요.
• 자동 테스트를 실행합니다.
• 설치 결과를 평가하십시오.
• 테스트 명령 측에서 다음 파이프라인을 호출합니다.

다음 파이프라인은 Jira에 작업을 등록하고 작업 구현 타이밍에 따라 선택된 테스트 루프에 명령이 배포될 때까지 기다려야 합니다. 트리거 - 특정 주소로 배송 준비가 완료되었음을 알리는 편지입니다. 물론 이것은 명백한 버팀목 이었지만 어딘가에서 시작해야했습니다. 2019년 XNUMX월, 환경 점검부터 코드 이전이 시작되었습니다. 프로세스가 시작되었으며 남은 것은 이를 적절한 형태로 만드는 것입니다.

• 각 수정은 설치 패키지에 해당하고 대상 마스터 분기에 병합되는 별도의 분기에서 수행됩니다.
• 파이프라인 실행 트리거는 병합 요청을 통해 마스터 브랜치에 새로운 커밋이 나타나는 것입니다. 이는 내부 팀의 유지 관리 담당자가 닫습니다.
• 리포지토리는 XNUMX분마다 한 번씩 동기화됩니다.
• 공급업체로부터 받은 어셈블러를 사용하여 설치 패키지 어셈블리가 시작됩니다.

그 이후에는 코드를 확인 및 전송하고, 파이프를 실행하고 우리 측에서 조립하는 기존 단계가 이미 있었습니다.

이 옵션은 XNUMX월에 출시되었습니다. 전환의 어려움으로 인해 공급업체와 일선 직원 사이에 약간의 불만이 생겼지만 다음 달에 걸쳐 우리는 모든 거친 부분을 제거하고 팀 간의 프로세스를 확립했습니다. 이제 커밋과 전달을 통해 어셈블리를 만들었습니다.
40월에는 파이프라인을 사용하여 프로덕션에 별도 패키지의 첫 번째 설치를 완료했으며, XNUMX월부터는 예외 없이 개별 미출시 패키지의 모든 설치가 CD 도구를 통해 수행되었습니다. 또한, 우리는 공급업체보다 작은 팀으로 릴리스 구성의 XNUMX%에 대한 내부 작업 공유를 달성했습니다. 이는 확실한 성공입니다. 가장 심각한 작업은 릴리스를 조립하고 설치하는 것입니다.

최종 솔루션: 누적 설치 패키지 

우리는 공급업체의 지침을 스크립팅하는 것이 그저 자동화라는 점을 완벽하게 이해했으며 프로세스 자체를 다시 생각해야 했습니다. 해결책은 분명했습니다. 필요한 버전의 모든 개체가 포함된 릴리스 분기에서 누적 공급을 수집하는 것입니다.

우리는 개념 증명부터 시작했습니다. 과거 구현 내용에 따라 릴리스 패키지를 손으로 조립하고 환경에 설치했습니다. 모든 것이 잘 풀렸고 개념이 실행 가능한 것으로 나타났습니다. 다음으로 초기화 설정을 스크립팅하고 이를 커밋에 포함하는 문제를 해결했습니다. 우리는 윤곽선 업데이트의 일환으로 새로운 패키지를 준비하고 테스트 환경에서 테스트했습니다. 구현 팀의 다양한 의견에도 불구하고 설치는 성공적이었습니다. 그러나 가장 중요한 것은 우리가 어셈블리를 통해 XNUMX월 릴리스에서 생산에 들어갈 수 있다는 허가를 받았다는 것입니다.

한 달 남짓 남은 상황에서 엄선된 소모품은 시간이 얼마 남지 않았음을 분명히 암시했습니다. 릴리스 브랜치에서 빌드하기로 결정했는데 왜 분리해야 합니까? Prod와 같은 브랜치가 없고 기존 브랜치가 좋지 않습니다. 불필요한 코드가 많습니다. 긴급하게 자극적인 커밋을 줄여야 하는데 이는 XNUMX개가 넘는 커밋입니다. 손으로 조립하는 것은 전혀 선택 사항이 아닙니다. 우리는 제품 설치 로그를 통해 실행되고 브랜치에 대한 커밋을 수집하는 스크립트를 스케치했습니다. 세 번째에는 올바르게 작동했고 "파일로 마무리"한 후에 브랜치가 준비되었습니다. 

우리는 설치 패키지에 대한 자체 빌더를 작성하고 일주일 만에 완료했습니다. 그런 다음 오픈 소스이기 때문에 시스템의 핵심 기능에서 설치 프로그램을 수정해야 했습니다. 일련의 확인과 수정 끝에 결과는 성공적인 것으로 간주되었습니다. 그 동안 릴리스 구성이 구체화되었으며 올바른 설치를 위해서는 테스트 회로를 프로덕션 회로와 정렬해야했으며 이를 위해 별도의 스크립트가 작성되었습니다.

당연히 첫 설치에 대한 댓글이 많았지만 전반적으로 코드는 작동했습니다. 세 번째 설치 후에는 모든 것이 괜찮아 보이기 시작했습니다. 객체의 구성 제어와 버전 제어는 수동 모드에서 별도로 모니터링되었으며, 이 단계에서는 상당히 타당했습니다.

또 다른 과제는 고려해야 할 미출시 작품의 수가 많다는 점이었습니다. 그러나 Prod와 유사한 브랜치와 Rebase를 사용하면 작업이 투명해졌습니다.

처음으로, 빠르고 오류 없이

우리는 낙관적인 태도로 출시에 접근했고 다양한 회로에서 XNUMX개 이상의 성공적인 설치를 거쳤습니다. 그러나 문자 그대로 마감일 하루 전에 공급업체가 승인된 방식으로 설치 릴리스를 준비하는 작업을 완료하지 않은 것으로 나타났습니다. 어떤 이유로든 빌드가 작동하지 않으면 릴리스가 중단됩니다. 더욱이 우리의 노력을 통해 특히 불쾌한 일이 발생했습니다. 우리는 후퇴할 길이 없었습니다. 따라서 우리는 대체 옵션을 고려하고 실행 계획을 준비한 후 설치를 시작했습니다.

놀랍게도 800개 이상의 개체로 구성된 전체 릴리스가 단 10분 만에 처음으로 올바르게 시작되었습니다. 오류가 있는지 로그를 확인하는 데 한 시간을 보냈지만 오류가 발견되지 않았습니다.

다음날 내내 릴리스 채팅에는 침묵이 흘렀습니다. 구현 문제, 비뚤어진 버전 또는 "부적절한" 코드가 없었습니다. 왠지 어색하기도 했어요. 이후 일부 댓글이 등장했지만, 다른 시스템이나 이전 경험에 비해 그 수와 우선순위가 눈에 띄게 낮았다.

누적 효과의 추가 효과는 조립 및 테스트 품질의 향상이었습니다. 전체 릴리스의 여러 설치로 인해 빌드 결함 및 배포 오류가 적시에 식별되었습니다. 전체 릴리스 구성에서 테스트하면 증분 설치 중에 나타나지 않았던 개체의 상호 영향에 대한 결함을 추가로 식별할 수 있었습니다. 특히 출시에 대한 우리의 기여도가 57%라는 점을 고려하면 확실히 성공했습니다.

결과 및 결론

XNUMX년도 채 되지 않아 우리는 다음과 같은 성과를 거두었습니다.

• 이국적인 시스템을 사용하여 본격적인 내부 개발을 구축하십시오.
• 중요한 공급업체 종속성을 제거합니다.
• 매우 비우호적인 레거시를 위해 CI/CD를 출시합니다.
• 구현 프로세스를 새로운 기술 수준으로 끌어올립니다.
• 배포 시간을 대폭 단축합니다.
• 구현 오류 수를 대폭 줄입니다.
• 자신이 최고의 개발 전문가임을 자신 있게 선언하세요.

물론 설명된 내용의 대부분은 완전히 허튼 소리처럼 보이지만 이는 시스템의 기능과 시스템에 존재하는 프로세스 제한 사항입니다. 현재 변경 사항은 IS 프로필 제품 및 서비스(마스터 계정, 플라스틱 카드, 저축 계좌, 에스크로, 현금 대출)에 영향을 주지만 잠재적으로 이 접근 방식은 DevOps 관행 구현 작업이 설정된 모든 IS에 적용될 수 있습니다. 누적 모델은 여러 전달의 후속 구현(비릴리스 구현 포함)을 위해 안전하게 복제될 수 있습니다.

출처 : habr.com