코드형 인프라: XP를 사용하여 문제를 극복하는 방법

안녕, 하브르! 이전에는 코드 패러다임으로서의 인프라에서의 삶에 대해 불평하고 현재 상황을 해결하기 위해 아무것도 제공하지 않았습니다. 오늘 저는 절망의 심연에서 벗어나 상황을 올바른 방향으로 이끄는 데 어떤 접근 방식과 실천이 도움이 되는지 말씀드리려고 돌아왔습니다.

이전 기사에서 "코드로서의 인프라: 첫 만남" 나는 이 분야에 대한 나의 인상을 공유하고, 이 분야의 현재 상황을 반영하려고 노력했으며, 심지어 모든 개발자에게 알려진 표준 관행이 도움이 될 수 있다고 제안했습니다. 생활에 대한 불만은 많은 것 같지만 현재 상황에서 벗어날 방법에 대한 제안은 없었습니다.

우리가 누구인지, 어디에 있는지, 어떤 문제가 있는지

우리는 현재 프로그래머 XNUMX명과 인프라 엔지니어 XNUMX명으로 구성된 Sre 온보딩 팀에 속해 있습니다. 우리는 모두 IaC(Infrastructure as Code)를 작성하려고 노력하고 있습니다. 우리는 기본적으로 코드 작성 방법을 알고 있고 "평균 이상의" 개발자였던 경력을 갖고 있기 때문에 이렇게 합니다.

• 우리는 특정 배경, 실무에 대한 지식, 코드 작성 능력, 새로운 것을 배우려는 열망 등 일련의 장점을 가지고 있습니다.
• 그리고 처지는 부분도 있는데, 이것도 마이너스입니다. 인프라 하드웨어에 대한 지식이 부족합니다.

IaC에서 사용하는 기술 스택입니다.

• 리소스 생성을 위한 Terraform.
• 이미지 조립을 위한 패커입니다. Windows, CentOS 7 이미지입니다.
• Jsonnet을 사용하면 Drone.io에서 강력한 빌드를 만들고 packer json과 terraform 모듈을 생성할 수 있습니다.
• 푸른.
• 이미지를 준비할 때 Ansible을 사용하세요.
• 보조 서비스 및 프로비저닝 스크립트를 위한 Python.
• 그리고 이 모든 것이 팀 구성원 간에 공유되는 플러그인을 사용하여 VSCode에 있습니다.

내 결론 마지막 기사 나는 (우선 나 자신에게) 낙관주의를 심어 주려고 노력했고, 이 분야에 존재하는 어려움과 복잡성을 다루기 위해 우리에게 알려진 접근 방식과 관행을 시도해 보겠다고 말하고 싶었습니다.

우리는 현재 다음과 같은 IaC 문제로 어려움을 겪고 있습니다.

• 코드 개발을 위한 도구 및 수단의 불완전성.
• 느린 배포. 인프라는 현실 세계의 일부이므로 속도가 느릴 수 있습니다.
• 접근 방식과 관행이 부족합니다.
• 우리는 새롭고 아는 것이 많지 않습니다.

익스트림 프로그래밍(XP)을 통해 구출

모든 개발자는 XP(Extreme 프로그래밍)와 그 뒤에 있는 방식에 익숙합니다. 우리 중 많은 사람들이 이 접근 방식을 사용해 왔으며 성공했습니다. 그렇다면 인프라 문제를 극복하기 위해 여기에 명시된 원칙과 관행을 사용하는 것은 어떨까요? 우리는 이 접근 방식을 취하고 무슨 일이 일어나는지 살펴보기로 결정했습니다.

귀하의 산업에 대한 XP 접근 방식의 적용 가능성 확인다음은 XP가 적합한 환경과 XP가 우리와 어떤 관련이 있는지에 대한 설명입니다.

1. 동적으로 변화하는 소프트웨어 요구 사항. 최종 목표가 무엇인지는 우리에게 분명했습니다. 그러나 세부 사항은 다를 수 있습니다. 우리는 택시를 타야 할 곳을 스스로 결정하므로 요구 사항은 주기적으로 (주로 우리 스스로) 변경됩니다. 자동화 자체를 수행하고 자체적으로 작업 요구 사항과 범위를 제한하는 SRE 팀을 선택한다면 이 점이 잘 들어맞습니다.

2. 신기술을 이용한 고정기간 프로젝트로 인한 위험. 우리에게 알려지지 않은 것들을 사용할 때 위험에 직면할 수 있습니다. 그리고 이것은 100% 우리의 경우입니다. 우리의 전체 프로젝트는 우리가 완전히 익숙하지 않은 기술을 사용하는 것이었습니다. 일반적으로 이는 지속적인 문제입니다. 왜냐하면... 인프라 부문에는 항상 새로운 기술이 많이 등장하고 있습니다.

3,4. 소규모로 공동 배치된 확장 개발 팀. 귀하가 사용하고 있는 자동화된 기술은 단위 및 기능 테스트를 허용합니다. 이 두 가지 점은 우리에게 적합하지 않습니다. 첫째, 우리는 조율된 팀이 아니며, 둘째, 우리는 14명이므로 대규모 팀이라고 할 수 있습니다. 하지만 "대규모" 팀의 일부 정의에 따르면 XNUMX명 이상이 팀입니다.

일부 XP 사례를 살펴보고 이것이 피드백의 속도와 품질에 어떤 영향을 미치는지 살펴보겠습니다.

XP 피드백 루프 원리

내가 이해하는 바에 따르면, 피드백은 내가 옳은 일을 하고 있는지, 우리가 거기까지 갈 것인가?라는 질문에 대한 답입니다. XP에는 이를 위한 신성한 계획, 즉 시간 피드백 루프가 있습니다. 흥미로운 점은 낮은 수준일수록 OS가 필요한 질문에 더 빨리 답할 수 있다는 것입니다.

우리 IT 산업에서는 OS를 빠르게 얻을 수 있다는 점은 다소 흥미로운 토론 주제입니다. XNUMX개월 동안 프로젝트를 수행하고 나서야 처음부터 실수가 있었다는 것을 알게 된다면 얼마나 고통스러울지 상상해 보십시오. 이는 설계와 복잡한 시스템 구축에서 발생합니다.

IaC의 경우 피드백이 도움이 됩니다. 즉시 위의 다이어그램을 약간 조정하겠습니다. 릴리스 계획에는 월별 주기가 없고 하루에 여러 번 발생합니다. 이 OS 주기와 관련된 몇 가지 사례를 더 자세히 살펴보겠습니다.

중요: 피드백은 위에서 언급한 모든 문제에 대한 해결책이 될 수 있습니다. XP 사례와 결합하면 절망의 심연에서 벗어날 수 있습니다.

절망의 심연에서 벗어나는 방법: 세 가지 실천

테스트

테스트는 XP 피드백 루프에서 두 번 언급됩니다. 그것은 단지 그런 것이 아닙니다. 이는 전체 익스트림 프로그래밍 기술에 매우 중요합니다.

단위 및 승인 테스트가 있다고 가정합니다. 일부는 몇 분 안에 피드백을 제공하고 다른 일부는 며칠 내에 피드백을 제공하므로 작성하는 데 시간이 더 오래 걸리고 검토 빈도도 줄어듭니다.

더 많은 테스트가 있어야 함을 보여주는 고전적인 테스트 피라미드가 있습니다.

이 프레임워크는 IaC 프로젝트에서 우리에게 어떻게 적용됩니까? 사실... 전혀 그렇지 않아요.

• 단위 테스트는 많아야 한다는 사실에도 불구하고 너무 많아서는 안 됩니다. 또는 매우 간접적으로 무언가를 테스트하고 있습니다. 사실 우리는 그것들을 전혀 쓰지 않는다고 말할 수 있습니다. 그러나 우리가 수행할 수 있었던 이러한 테스트에 대한 몇 가지 응용 프로그램은 다음과 같습니다.
  1. jsonnet 코드를 테스트 중입니다. 예를 들어, 이것은 상당히 복잡한 드론 조립 파이프라인입니다. jsonnet 코드는 테스트를 통해 잘 다루어집니다.
     우리는 이것을 사용합니다 Jsonnet용 단위 테스트 프레임워크.
  2. 리소스가 시작될 때 실행되는 스크립트를 테스트합니다. 스크립트는 Python으로 작성되므로 테스트를 작성할 수 있습니다.
• 테스트에서 구성을 확인하는 것이 잠재적으로 가능하지만 우리는 그렇게 하지 않습니다. 다음을 통해 리소스 구성 규칙 확인을 구성할 수도 있습니다. 티플린트. 그러나 여기의 검사는 Terraform에 비해 너무 기본적이지만 많은 테스트 스크립트는 AWS용으로 작성되었습니다. 그리고 우리는 Azure를 사용하고 있으므로 이는 다시 적용되지 않습니다.
• 구성 요소 통합 테스트: 분류 방법과 배치 위치에 따라 다릅니다. 그러나 그들은 기본적으로 작동합니다.

  이것이 통합 테스트의 모습입니다.

  
  
  Drone CI에서 이미지를 구축할 때의 예시입니다. 여기에 도달하려면 Packer 이미지가 형성될 때까지 30분을 기다린 다음 통과할 때까지 15분을 더 기다려야 합니다. 하지만 그들은 존재합니다!

  이미지 검증 알고리즘

  1. 패커는 먼저 이미지를 완전히 준비해야 합니다.
  2. 테스트 옆에는 이 이미지를 배포하는 데 사용하는 로컬 상태가 있는 테라폼이 있습니다.
  3. 펼칠 때 이미지 작업을 더 쉽게 하기 위해 근처에 있는 작은 모듈을 사용합니다.
  4. 이미지에서 VM이 배포되면 검사를 시작할 수 있습니다. 기본적으로 점검은 자동차로 이루어집니다. 시작 시 스크립트가 작동하는 방식과 데몬이 작동하는 방식을 확인합니다. 이를 위해 ssh 또는 winrm을 통해 새로 생성된 시스템에 로그인하고 구성 상태 또는 서비스가 작동 중인지 확인합니다.

• 상황은 Terraform용 모듈의 통합 테스트와 유사합니다. 다음은 이러한 테스트의 기능을 설명하는 간단한 표입니다.

  
  
  파이프라인에 대한 피드백은 약 40분 정도 소요됩니다. 모든 일은 아주 오랜 시간 동안 일어납니다. 회귀 분석에는 사용할 수 있지만 새로운 개발에는 일반적으로 비현실적입니다. 이에 대한 준비가 매우 잘 되어 있다면 실행 스크립트를 준비하고 이를 10분으로 줄일 수 있습니다. 하지만 이는 여전히 5초 안에 100개의 조각을 수행하는 단위 테스트가 아닙니다.

이미지 또는 Terraform 모듈을 어셈블할 때 단위 테스트가 없기 때문에 작업을 REST를 통해 간단히 실행할 수 있는 별도의 서비스나 Python 스크립트로 전환하는 것이 좋습니다.

예를 들어, 가상 머신이 시작되면 서비스에 등록되는지 확인해야 했습니다. ScaleFT, 가상 머신이 파괴되면 자체적으로 삭제되었습니다.

ScaleFT를 서비스로 갖고 있으므로 API를 통해 작업해야 합니다. 거기에는 "들어가서 이것저것 삭제해"라고 말할 수 있는 래퍼가 적혀 있었습니다. 필요한 모든 설정과 액세스를 저장합니다.

일반 소프트웨어와 다르지 않기 때문에 우리는 이미 이에 대한 일반 테스트를 작성할 수 있습니다. 일종의 apiha가 조롱되고 끌어당겨 무슨 일이 일어나는지 확인합니다.

테스트 결과: XNUMX분 안에 OS를 제공해야 하는 단위 테스트가 제공되지 않습니다. 그리고 피라미드에서 더 높은 수준의 테스트 유형은 효과적이지만 문제의 일부만 다루고 있습니다.

페어 프로그래밍

테스트는 물론 좋습니다. 많이 쓸 수 있고 다양한 유형이 될 수 있습니다. 그들은 각자의 수준에 맞게 작업하고 피드백을 제공할 것입니다. 그러나 가장 빠른 OS를 제공하는 잘못된 단위 테스트의 문제는 여전히 남아 있습니다. 동시에, 나는 여전히 쉽고 즐겁게 작업할 수 있는 빠른 OS를 원합니다. 결과 솔루션의 품질은 말할 것도 없습니다. 다행히도 단위 테스트보다 더 빠른 피드백을 제공할 수 있는 기술이 있습니다. 이것이 페어 프로그래밍이다.

코드를 작성할 때 가능한 한 빨리 품질에 대한 피드백을 받고 싶습니다. 예, 기능 브랜치에 모든 내용을 작성하고(다른 사람의 내용을 손상시키지 않도록) Github에서 끌어오기 요청을 만들고 의견이 중요한 사람에게 할당하고 응답을 기다릴 수 있습니다.

하지만 오래 기다릴 수 있습니다. 사람들은 모두 바쁘기 때문에 답변이 있더라도 품질이 최고가 아닐 수도 있습니다. 답변이 즉시 왔고 리뷰어는 전체 아이디어를 즉시 이해했지만 사실 이후에도 여전히 답변이 늦었다고 가정해 보겠습니다. 더 일찍 그랬으면 좋았을 텐데요. 이것이 바로 이 글을 쓰는 시점에서 페어 프로그래밍이 목표로 하는 것입니다.

다음은 IaC 작업 시 쌍 프로그래밍 스타일과 적용 가능성입니다.

1. 클래식, 경험+경험, 타이머에 의한 교대. 두 가지 역할 - 운전자와 내비게이터. 두 사람. 그들은 동일한 코드로 작업하고 일정 기간이 지나면 역할을 바꿉니다.

스타일과 관련된 문제의 호환성을 고려해 보겠습니다.

• 문제: 코드 개발을 위한 도구 및 도구의 불완전성.
  부정적인 영향: 개발하는 데 시간이 더 오래 걸리고 속도가 느려지며 작업 속도/리듬이 사라집니다.
  우리가 싸우는 방법: 우리는 다른 도구, 공통 IDE를 사용하고 단축키도 배웁니다.
• 문제: 느린 배포.
  부정적인 영향: 작동하는 코드를 생성하는 데 걸리는 시간이 늘어납니다. 기다리는 동안 우리는 지루해지고, 기다리는 동안 다른 일을 하려고 손을 뻗습니다.
  우리가 싸우는 방법: 우리는 그것을 극복하지 못했습니다.
• 문제: 접근 방식과 관행이 부족합니다.
  부정적인 영향: 어떻게 하면 잘할지, 어떻게 하면 잘못할지에 대한 지식이 없습니다. 피드백 수신 시간이 길어집니다.
  우리가 싸우는 방법: 쌍으로 작업하면서 의견과 관행을 상호 교환하면 문제가 거의 해결됩니다.

IaC에서 이 스타일을 사용할 때의 주요 문제점은 작업 속도가 고르지 않다는 것입니다. 전통적인 소프트웨어 개발에서는 움직임이 매우 균일합니다. 10분을 투자해서 N을 쓰면 됩니다. 2분을 투자하고 15N, 3분 - 30N을 쓰면 됩니다. 여기서는 XNUMX분을 투자해 N을 쓰고, 또 XNUMX분을 투자해 N의 XNUMX분의 XNUMX을 쓸 수 있습니다. 여기서는 아무것도 모르고, 꼼짝 못하게 됐습니다. 조사에는 시간이 걸리고 프로그래밍 자체에 방해가 됩니다.

결론: 순수한 형태로는 우리에게 적합하지 않습니다.

2. 탁구. 이 접근 방식에는 한 사람이 테스트를 작성하고 다른 사람이 이를 구현하는 작업이 포함됩니다. 단위 테스트로 모든 것이 복잡하고 프로그래밍하는 데 오랜 시간이 걸리는 통합 테스트를 작성해야 한다는 사실을 고려하면 탁구의 모든 용이성은 사라집니다.

테스트 스크립트를 설계하고 코드를 구현하는 책임을 분리하려고 노력했다고 말할 수 있습니다. 한 참가자가 대본을 생각해 냈는데, 그가 담당한 작업 부분에서 그는 마지막 말을 했습니다. 그리고 다른 하나는 구현을 담당했습니다. 잘 됐어요. 이 접근 방식을 사용하면 스크립트 품질이 향상됩니다.

결론: 안타깝게도 작업 속도로 인해 IaC에서 페어 프로그래밍 연습으로 탁구를 사용할 수 없습니다.

3. 강한 스타일. 어려운 연습. 아이디어는 한 참가자가 지시 탐색기가 되고 두 번째 참가자가 실행 드라이버의 역할을 맡는다는 것입니다. 이 경우 결정을 내릴 권리는 전적으로 네비게이터에게 있습니다. 운전자는 인쇄만 하고 단어로 일어나는 일에 영향을 미칠 수 있습니다. 역할은 오랫동안 변하지 않습니다.

학습에는 좋지만 강력한 소프트 스킬이 필요합니다. 이것이 우리가 흔들린 곳입니다. 기술이 어려웠습니다. 그리고 그것은 인프라에 관한 것도 아닙니다.

결론: 잠재적으로 사용될 수 있으며, 우리는 시도를 포기하지 않습니다.

4. 몰려들기, 무리 짓기 및 알려졌으나 목록에 없는 모든 스타일 우리는 그것을 고려하지 않습니다. 왜냐하면 우리는 그것을 시도한 적이 없으며 우리 작업의 맥락에서 그것에 대해 이야기하는 것은 불가능합니다.

쌍 프로그래밍 사용에 대한 일반적인 결과:

• 우리는 작업 속도가 고르지 않아 혼란스럽습니다.
• 우리는 충분하지 않은 소프트 스킬을 만났습니다. 그리고 주제 영역은 우리의 이러한 단점을 극복하는 데 도움이 되지 않습니다.
• 도구에 대한 오랜 테스트와 문제로 인해 쌍을 이루는 개발이 어려워집니다.

5. 그럼에도 불구하고 성공이 있었다. 우리는 우리만의 방법인 "Convergence - Divergence"를 생각해냈습니다. 어떻게 작동하는지 간략하게 설명하겠습니다.

우리는 며칠(XNUMX주일 미만) 동안 영구 파트너를 보유하고 있습니다. 우리는 하나의 임무를 함께 수행합니다. 우리는 한동안 함께 앉아 있습니다. 한 사람은 글을 쓰고, 다른 한 사람은 앉아서 지원팀을 지켜봅니다. 그런 다음 우리는 한동안 분산되어 각각 독립적인 작업을 수행한 다음 다시 모이고 매우 빠르게 동기화하고 함께 무언가를 수행하고 다시 분산됩니다.

기획 및 커뮤니케이션

OS 문제를 해결하는 마지막 관행 블록은 작업 자체를 사용한 작업 구성입니다. 여기에는 짝 작업 이외의 경험 교환도 포함됩니다. 세 가지 사례를 살펴보겠습니다.

1. 목표 트리를 통한 목표. 끝없이 미래를 향해 나아가는 나무를 통해 프로젝트의 전반적인 관리를 정리했습니다. 기술적으로 추적은 Miro에서 수행됩니다. 하나의 작업이 있습니다. 이는 중간 목표입니다. 여기에서 더 작은 목표나 작업 그룹이 나옵니다. 작업 자체는 그들에게서 나옵니다. 모든 작업은 이 보드에서 생성되고 유지됩니다.

이 체계는 또한 집회에서 동기화할 때 하루에 한 번 발생하는 피드백을 제공합니다. 모든 사람 앞에 공통 계획을 세우되 구조화되고 완전히 공개되어 있으면 모든 사람이 무슨 일이 일어나고 있는지, 우리가 얼마나 발전했는지 알 수 있습니다.

작업에 대한 시각적 비전의 장점:

• 인과관계. 각 작업은 글로벌 목표로 이어집니다. 작업은 더 작은 목표로 그룹화됩니다. 인프라 도메인 자체는 상당히 기술적입니다. 예를 들어, 다른 nginx로의 마이그레이션에 대한 런북 작성이 비즈니스에 미치는 구체적인 영향이 무엇인지 항상 즉시 명확하지는 않습니다. 대상 카드가 근처에 있으면 더 명확해집니다.
  
  인과성은 문제의 중요한 속성이다. “내가 옳은 일을 하고 있는 걸까?”라는 질문에 직접적으로 대답합니다.
• 병행. 우리는 아홉 명인데 모두를 한 가지 작업에 투입하는 것은 물리적으로 불가능합니다. 한 영역의 작업만으로는 항상 충분하지 않을 수도 있습니다. 우리는 소규모 작업 그룹 간의 작업을 병렬화해야 합니다. 동시에 그룹은 한동안 자신의 임무를 수행하며 다른 사람에 의해 강화될 수 있습니다. 때때로 사람들은 이 작업 그룹에서 멀어집니다. 누군가는 휴가를 가고, 누군가는 DevOps conf에 대한 보고서를 작성하고, 누군가는 Habr에 기사를 씁니다. 어떤 목표와 작업을 동시에 수행할 수 있는지 아는 것이 매우 중요합니다.

2. 아침회의 발표자를 교체합니다. 스탠드업에서는 이런 문제가 있습니다. 사람들은 많은 작업을 동시에 수행합니다. 때로는 작업이 느슨하게 연결되어 누가 무엇을 하고 있는지 이해하지 못하는 경우도 있습니다. 그리고 다른 팀원의 의견도 매우 중요합니다. 이는 문제 해결 과정을 변경할 수 있는 추가 정보입니다. 물론 일반적으로 누군가와 함께 있지만 조언과 팁은 항상 유용합니다.

이러한 상황을 개선하기 위해 우리는 '리딩 스탠드업 변경' 기법을 사용했습니다. 이제 특정 목록에 따라 회전되며 이것이 효과가 있습니다. 당신의 차례가 되면, 좋은 스크럼 회의를 진행하기 위해 뛰어들어 무슨 일이 일어나고 있는지 이해해야 합니다.

3. 내부 데모. 페어 프로그래밍을 통한 문제 해결 지원, 문제 트리 시각화, 오전 스크럼 회의 지원은 좋지만 이상적이지는 않습니다. 부부로서 당신은 지식에 의해서만 제한됩니다. 작업 트리는 누가 무엇을 하고 있는지 전체적으로 이해하는 데 도움이 됩니다. 그리고 아침 회의의 발표자와 동료는 귀하의 문제에 대해 깊이 파고 들지 않을 것입니다. 그들은 확실히 뭔가를 놓칠 수도 있습니다.

해결 방법은 서로에게 작업을 보여주고 토론하는 것에서 찾았습니다. 우리는 일주일에 한 번씩 한 시간씩 만나 지난 한 주 동안 우리가 수행한 작업에 대한 해결 방법을 자세히 보여줍니다.

시연 중에는 작업의 세부 사항을 공개하고 해당 작업의 작동을 시연해야 합니다.

보고서는 체크리스트를 사용하여 수행할 수 있습니다.1. 상황을 살펴보세요. 그 작업은 어디서 왔으며, 왜 필요했습니까?

2. 이전에는 문제가 어떻게 해결되었나요? 예를 들어 엄청난 양의 마우스 클릭이 필요했거나 전혀 아무것도 할 수 없었습니다.

3. 이를 개선하는 방법. 예: "이제 scriptosik이 있고 여기에 readme가 있습니다."

4. 그것이 어떻게 작동하는지 보여주세요. 일부 사용자 시나리오를 직접 구현하는 것이 좋습니다. 나는 X를 원하고, Y를 하고, Y(또는 Z)를 봅니다. 예를 들어 NGINX를 배포하고 URL을 연기한 후 200 OK를 얻습니다. 동작이 길다면 나중에 보여줄 수 있도록 미리 준비하세요. 깨지기 쉬운 경우 데모 한 시간 전에 너무 많이 깨지 않는 것이 좋습니다.

5. 문제가 얼마나 성공적으로 해결되었는지, 남은 어려움은 무엇인지, 아직 완료되지 않은 부분은 무엇인지, 앞으로 어떤 개선이 가능한지 설명하십시오. 예를 들어, 이제 CLI가 있다면 CI에는 완전 자동화가 있을 것입니다.

각 발언자는 5~10분 정도를 유지하는 것이 좋습니다. 귀하의 연설이 분명히 중요하고 시간이 더 오래 걸릴 경우, 인수 채널에서 사전에 이를 조정하십시오.

대면 부분 이후에는 항상 스레드에서 토론이 있습니다. 작업에 필요한 피드백이 나타나는 곳입니다.

결과적으로 현재 상황의 유용성을 판단하기 위해 설문 조사가 수행됩니다. 이것은 연설의 본질과 과제의 중요성에 대한 피드백입니다.

긴 결론과 다음 단계

기사의 어조가 다소 비관적인 것처럼 보일 수도 있습니다. 이것은 잘못된 것입니다. 두 가지 낮은 수준의 피드백, 즉 테스트와 쌍 프로그래밍이 작동합니다. 전통적인 개발만큼 완벽하지는 않지만 긍정적인 효과가 있습니다.

현재 형태의 테스트는 부분적인 코드 적용 범위만 제공합니다. 많은 구성 기능이 테스트되지 않은 상태로 종료됩니다. 코드를 작성할 때 실제 작업에 미치는 영향은 낮습니다. 그러나 통합 테스트의 효과가 있으며 이를 통해 두려움 없이 리팩토링을 수행할 수 있습니다. 이것은 대단한 성과입니다. 또한 고급 언어(우리는 Python, go를 사용함) 개발로 초점이 이동함에 따라 문제가 사라집니다. 그리고 "접착제"에 대해서는 많은 확인이 필요하지 않으며 일반적인 통합 확인만으로 충분합니다.

쌍으로 작업하는 것은 특정 사람들에 따라 더 많이 달라집니다. 작업 요소와 소프트 스킬이 있습니다. 어떤 사람들에게는 그것이 매우 잘 풀리고, 다른 사람들에게는 더 나쁘게 작용합니다. 이것으로부터 확실히 이점이 있습니다. 쌍 작업 규칙이 충분히 준수되지 않더라도 함께 작업을 수행한다는 사실 자체가 결과의 품질에 긍정적인 영향을 미치는 것은 분명합니다. 개인적으로 저는 둘이서 작업하는 것이 더 쉽고 즐겁다고 생각합니다.

OS에 영향을 미치는 더 높은 수준의 방법 - 작업을 정확하게 계획하고 작업하면 고품질 지식 교환 및 개발 품질 향상과 같은 효과가 발생합니다.

한 줄로 짧은 결론

• HR 실무자는 IaC에서 일하지만 효율성은 떨어집니다.
• 효과가 있는 것을 강화하세요.
• 자신만의 보상 메커니즘과 관행을 생각해 보세요.

출처 : habr.com