Jenkins가 아닌 실습으로서의 지속적인 통합. 안드레이 알렉산드로프

CI 도구와 CI가 완전히 다른 이유에 대해 논의해 보겠습니다.

CI가 해결하려는 문제는 무엇인지, 아이디어는 어디서 왔는지, 작동하는지에 대한 최신 확인은 무엇인지, Jenkins를 설치한 것이 아니라 실습이 있다는 것을 이해하는 방법입니다.

지속적인 통합에 대한 보고서를 작성하겠다는 아이디어는 10년 전 제가 면접을 보러 가고 일자리를 찾을 때 나타났습니다. 15~XNUMX개 회사와 이야기를 나눴는데 그중 한 곳에서만 CI가 무엇인지 명확하게 답하고 CI가 없다는 것을 어떻게 깨달았는지 설명할 수 있었습니다. 나머지는 Jenkins에 대해 이해할 수 없는 말도 안되는 이야기를 하고 있었습니다. :) 글쎄요, Jenkins가 있고 CI도 빌드합니다! 보고서에서 저는 지속적인 통합이 실제로 무엇인지, 그리고 왜 Jenkins 및 유사한 도구가 이것과 매우 약한 관계를 가지고 있는지 설명하려고 노력할 것입니다.

그렇다면 CI라는 단어를 들으면 보통 무엇이 떠오르나요? 대부분의 사람들은 Jenkins, Gitlab CI, Travis 등을 생각할 것입니다.

Google에서 검색해도 이러한 도구가 제공됩니다.

질문하는 데 익숙하다면 도구를 나열한 직후에 커밋에 대한 풀 요청에서 테스트를 빌드하고 실행할 때 CI가 있다는 것을 알려줄 것입니다.

지속적인 통합은 도구나 브랜치의 테스트가 포함된 어셈블리에 관한 것이 아닙니다! 지속적인 통합은 새로운 코드를 매우 자주 통합하는 관행이며 이를 사용하기 위해 Jenkins, GitLab 등을 차단할 필요가 전혀 없습니다.

본격적인 CI가 어떤 모습인지 알아보기 전에 먼저 CI를 생각해낸 사람들의 맥락을 살펴보고 그들이 해결하려고 했던 고통을 느껴보겠습니다.

그리고 그들은 팀으로 함께 일하는 고통을 해결했습니다!

개발자가 팀으로 개발할 때 직면하는 어려움의 예를 살펴보겠습니다. 여기에 프로젝트, git의 마스터 브랜치, 두 명의 개발자가 있습니다.

그리고 그들은 모두가 오랫동안 익숙해 졌던 것처럼 일하러갔습니다. 우리는 전체적인 계획에 따라 작업을 수행하고 기능 브랜치를 생성하고 코드를 작성했습니다.

하나는 기능을 더 빨리 완료하고 이를 마스터에 병합했습니다.

두 번째는 시간이 더 필요했고 나중에 병합되어 충돌이 발생했습니다. 이제 개발자는 비즈니스에 필요한 기능을 작성하는 대신 갈등을 해결하는 데 시간과 에너지를 소비합니다.

귀하의 기능을 공통 마스터와 결합하는 것이 어려울수록 우리는 이에 소요되는 시간을 더 많이 사용합니다. 그리고 저는 이것을 매우 간단한 예를 통해 보여주었습니다. 이것은 개발자가 2명뿐인 예인데, 회사에서 10명, 15명, 100명이 하나의 저장소에 글을 쓴다고 상상해 보세요. 이 모든 갈등을 해결하려면 미쳐버릴 것입니다.

약간 다른 경우도 있습니다. 우리에게는 마스터와 일부 개발자가 뭔가를 하고 있습니다.

그들은 나뭇가지를 만들었습니다.

한 명은 죽었고 모든 것이 괜찮았고 임무를 통과했습니다.

그 사이 두 번째 개발자가 자신의 임무를 맡겼습니다. 그가 검토를 위해 보냈다고 가정 해 보겠습니다. 많은 회사에는 검토라는 관행이 있습니다. 이 수행은 한편으로는 좋고 유용하지만, 다른 한편으로는 여러 면에서 우리의 속도를 늦추게 됩니다. 이에 대해 자세히 다루지는 않겠지만, 여기에 나쁜 리뷰 스토리가 어떤 결과를 가져올 수 있는지 보여주는 좋은 예가 있습니다. 검토를 위해 풀 요청을 제출했습니다. 개발자가 더 이상 할 일은 없습니다. 그는 무엇을 시작합니까? 그는 다른 일을 맡기 시작합니다.

이 기간 동안 두 번째 개발자는 다른 작업을 수행했습니다.

첫 번째는 세 번째 작업을 완료했습니다.

그리고 오랜 시간이 흐른 후 그의 리뷰가 테스트를 거쳤고 그는 합의를 이루기 위해 노력하고 있습니다. 그래서 무슨 일이야? 그것은 엄청난 수의 갈등을 포착합니다. 왜? 왜냐하면 그의 풀 리퀘스트가 리뷰에 걸려 있는 동안 이미 코드에서 많은 것이 변경되었기 때문입니다.

갈등이 있는 이야기 외에도 소통이 있는 이야기가 있습니다. 스레드가 검토 중인 동안, 무언가를 기다리고 있는 동안, 오랫동안 기능에 대해 작업하는 동안 서비스의 코드 베이스에서 변경되는 다른 사항에 대한 추적을 중단합니다. 아마도 지금 해결하려는 것이 어제 이미 해결되었으므로 어떤 방법을 사용하여 다시 사용할 수 있습니다. 하지만 항상 오래된 브랜치로 작업하고 있기 때문에 이 내용은 표시되지 않습니다. 그리고 이 오래된 분기로 인해 항상 병합 충돌을 해결해야 합니다.

우리가 팀으로 작업하는 경우, 즉 한 사람이 아니라 5-10명이 저장소를 탐색하는 경우 마스터에 코드를 추가하지 않는 시간이 길어질수록 궁극적으로 필요하기 때문에 더 많은 고통을 겪게 됩니다. 그런 다음 병합하세요. 충돌이 많을수록, 이전 버전으로 작업할수록 문제도 더 많아집니다.

함께 뭔가를하는 것은 고통 스럽습니다! 우리는 항상 서로의 길을 방해합니다.

이 문제는 20여년 전에 나타났습니다. 나는 익스트림 프로그래밍에서 지속적인 통합에 대한 첫 번째 언급을 발견했습니다.

익스트림 프로그래밍은 최초의 애자일 프레임워크입니다. 이 페이지는 96년에 등장했습니다. 그리고 어떤 종류의 프로그래밍 방식, 계획 및 기타 사항을 사용하여 개발을 최대한 유연하게 하여 고객의 변경 사항이나 요구 사항에 신속하게 대응할 수 있도록 하는 것이 아이디어였습니다. 그리고 그들은 24년 전부터 이 문제에 직면하기 시작했습니다. 어떤 일을 매우 오랫동안 부업으로 수행하면 갈등이 있기 때문에 그것에 더 많은 시간을 소비하게 된다는 것입니다.

이제 "지속적 통합"이라는 문구를 개별적으로 분석하겠습니다. 직접 번역하면 지속적인 통합이 이루어집니다. 그러나 그것이 얼마나 연속적인지는 명확하지 않으며 매우 불연속적입니다. 그러나 그것이 얼마나 통합되어 있는지도 그다지 명확하지 않습니다.

이것이 바로 제가 지금 여러분에게 Extreme 프로그래밍의 인용문을 제공하는 이유입니다. 그리고 우리는 두 단어를 별도로 분석할 것입니다.

통합 - 이미 말했듯이 우리는 모든 엔지니어가 최신 버전의 코드로 작업하도록 노력하여 가능한 한 자주 자신의 코드를 공통 분기에 추가하여 작은 분기가 되도록 노력합니다. 크기가 크면 일주일 동안 병합 충돌이 발생하기 쉽습니다. 개발자가 일부 거대한 기능을 삭제하기 위해 한 달 동안 자리를 비운 폭포수와 같이 개발 주기가 긴 경우 특히 그렇습니다. 그리고 그는 아주 오랫동안 통합 단계에 머물게 될 것이다.

통합은 브랜치를 마스터와 통합하고 병합하는 것입니다. 우리가 트랜스베이스 개발자라면 추가 브랜치 없이 즉시 마스터에 쓸 수 있도록 노력하는 궁극적인 옵션이 있습니다.

일반적으로 통합이란 코드를 가져와 마스터로 끌어오는 것을 의미합니다.

여기서 "연속"이라는 단어는 무엇을 의미합니까? 연속성이란 무엇입니까? 연습은 개발자가 자신의 코드를 가능한 한 빨리 통합하려고 노력한다는 것을 의미합니다. 모든 작업을 수행할 때 그의 목표는 가능한 한 빨리 그의 코드를 마스터로 가져오는 것입니다. 이상적인 세상에서 개발자는 몇 시간마다 이 작업을 수행합니다. 즉, 작은 문제를 가져와서 마스터에 병합합니다. 모든것이 좋아. 이것이 당신이 추구하는 것입니다. 그리고 이것은 지속적으로 이루어져야 합니다. 당신이 무엇인가를 하자마자, 당신은 그것을 즉시 마스터에 집어넣습니다.

그리고 무언가를 만드는 개발자는 그것이 작동하도록 하고 어떤 것도 깨지지 않게 하기 위해 자신이 한 일에 책임이 있습니다. 테스트 스토리는 보통 여기서 나옵니다. 우리는 커밋과 병합에 대해 몇 가지 테스트를 실행하여 제대로 작동하는지 확인하고 싶습니다. 이것이 Jenkins가 당신을 도울 수 있는 곳입니다.

하지만 스토리를 사용하면 변경 사항을 작게 만들고, 작업을 작게 만들고, 문제를 만들고 즉시 어떻게든 마스터에 삽입해 보겠습니다. 여기서는 Jenkins가 도움이 되지 않습니다. Jenkins는 테스트 실행에만 도움을 주기 때문입니다.

그들 없이도 할 수 있습니다. 이것은 당신에게 전혀 해를 끼치 지 않을 것입니다. 연습의 목표는 미래의 갈등에 엄청난 시간을 낭비하지 않도록 가능한 한 자주 측정하는 것이기 때문입니다.

어떤 이유에서인지 우리가 2020년에 인터넷이 없다고 상상해 봅시다. 그리고 우리는 현지에서 일합니다. 우리에겐 젠킨스가 없습니다. 이건 괜찮아. 계속 진행하여 로컬 지점을 만들 수 있습니다. 그 안에 몇 가지 코드를 작성했습니다. 우리는 3~4시간 만에 작업을 완료했습니다. 마스터로 전환하고 git pull을 수행한 후 거기에 브랜치를 병합했습니다. 준비가 된. 이 작업을 자주 수행한다면 축하합니다. 지속적인 통합이 이루어진 것입니다!

현대 사회에서 에너지를 투자할 가치가 있다는 증거는 무엇입니까? 일반적으로 어렵기 때문입니다. 이렇게 작업하려고 하면 이제 일부 계획이 영향을 받고 작업 분해에 더 많은 시간을 투자해야 한다는 것을 이해하게 될 것입니다. 왜냐면 남자... 그렇게 하면 빨리 합의하지 못해서 곤경에 빠지게 되거든요. 더 이상 연습할 필요가 없습니다.

그리고 그것은 비쌀 것입니다. Continuous Integration을 사용하면 내일부터 즉시 작업이 불가능합니다. 익숙해지는 데는 매우 오랜 시간이 걸릴 것이고, 작업을 분해하는 데는 매우 오랜 시간이 걸릴 것이며, 검토 연습을 다시 수행하는 데 익숙해지는 데도 매우 오랜 시간이 걸릴 것입니다. . 왜냐하면 우리의 목표는 오늘 녹이는 것이기 때문입니다. 그리고 XNUMX일 이내에 검토를 수행하면 문제가 발생하고 지속적인 통합이 효과가 없게 됩니다.

하지만 현재 이러한 관행에 투자하는 것이 합리적이라는 관련 증거가 있습니까?

내 마음에 가장 먼저 떠오른 것은 State of DevOps였습니다. 이것은 그 사람들이 7년 동안 수행해 온 연구입니다. 이제 그들은 독립적인 조직으로 이를 수행하지만 Google에서 수행합니다.

2018년 연구에서는 빠르게 통합하고 자주 통합하며 더 나은 IT 성과 지표를 갖춘 단기 지점을 사용하려는 기업 간의 상관 관계를 보여주었습니다.

이 지표는 무엇입니까? 배포 빈도, 변경 리드 타임, 서비스 복원 시간, 변경 실패율 등 설문조사를 통해 모든 회사로부터 취하는 4가지 지표는 다음과 같습니다.

그리고 첫째, 이러한 상관관계가 있습니다. 우리는 자주 측정하는 회사가 훨씬 더 나은 지표를 가지고 있다는 것을 알고 있습니다. 그리고 그들은 회사를 여러 범주로 구분합니다. 이들은 천천히 무언가를 생산하는 느린 회사, 중간 성과, 높은 성과 및 엘리트입니다. 엘리트는 초고속이며 모든 것을 빠르고 아름답고 효율적으로 수행하는 Netflix, Amazon입니다.

불과 한 달 전 일어난 두 번째 이야기. Technology Radar에는 Gitflow에 대한 훌륭한 기사가 있습니다. Gitflow는 브랜치가 오래 지속된다는 점에서 다른 모든 것과 다릅니다. 오랫동안 유지되는 릴리스 브랜치와 오랫동안 유지되는 기능 브랜치가 있습니다. Technology Radar의 이 관행은 HOLD로 전환되었습니다. 왜? 왜냐하면 사람들은 통합의 고통을 겪고 있기 때문입니다.

귀하의 브랜치가 아주 오랫동안 지속된다면, 브랜치는 꼼짝 못하게 되고, 썩게 되며, 우리는 브랜치에 변화를 주기 위해 더 많은 시간을 소비하기 시작합니다.

그리고 최근 Gitflow의 저자는 지속적인 통합이 목표이고 가능한 한 자주 롤링하는 것이 목표라면 Gitflow는 나쁜 생각이라고 말했습니다. 그는 별도로 기사에 추가했습니다. 이를 위해 노력할 수 있는 백엔드가 있다면 Gitflow는 불필요한 것입니다. Gitflow가 속도를 늦추기 때문에 Gitflow는 통합에 문제를 일으킬 것입니다.

이는 Gitflow가 나쁘고 사용해서는 안 된다는 의미는 아닙니다. 다른 경우를 위한 것입니다. 예를 들어 서비스나 애플리케이션의 여러 버전을 지원해야 하는 경우, 즉 장기간 지원이 필요한 경우입니다.

그런데 그런 서비스를 지원하는 분들과 이야기를 나눠보면 이번 버전이 3.2개월 전인 4 버전인데 이 픽스가 포함되어 있지 않아서 지금 만들려면, 많은 변화를 주어야 합니다. 그리고 이제 그들은 다시 막히게 되었고, 새로운 기능을 구현하기 위해 일주일 동안 이리저리 돌아다녔습니다.

Alexander Kovalev가 채팅에서 올바르게 언급했듯이 상관관계는 인과관계와 동일하지 않습니다. 이것은 사실이다. 즉, 지속적 통합이 있으면 모든 지표가 훌륭할 것이라는 직접적인 연관성은 없습니다. 그러나 하나가 하나라면 다른 하나도 그럴 가능성이 높다는 긍정적인 상관관계가 있습니다. 사실은 아니지만 가능성이 높습니다. 그것은 단지 상관관계일 뿐입니다.

우리는 이미 뭔가를 하고 있는 것 같고, 이미 병합하고 있는 것 같습니다. 하지만 우리가 여전히 지속적인 통합을 갖고 있고 꽤 자주 병합하고 있다는 것을 어떻게 이해할 수 있습니까?

Jez Humble은 Handbook, Accelerate, Continuous Delivery 웹 사이트 및 Continuous Delivery 책의 저자입니다. 그는 다음과 같은 테스트를 제공합니다.

• 엔지니어의 코드는 매일 마스터에게 전달됩니다.
• 모든 커밋에 대해 단위 테스트를 실행합니다.
• 마스터의 빌드가 떨어졌는데, 약 10분만에 고쳐졌습니다.

그는 충분한 연습이 있는지 확인하기 위해 이와 같은 테스트를 사용할 것을 제안합니다.

나는 후자가 약간 논란의 여지가 있다고 생각합니다. 즉, 10분 안에 문제를 해결할 수 있다면 지속적인 통합이 있는 것입니다. 제 생각에는 조금 이상하게 들리지만 말이 됩니다. 왜? 자주 정지하면 변경 사항이 적다는 의미이기 때문입니다. 작은 변경으로 인해 마스터 빌드가 손상되었음을 의미하는 경우 변경 사항이 작기 때문에 신속하게 예제를 찾을 수 있습니다. 여기서는 작은 병합이 있었고 20-30줄이 변경되었습니다. 따라서 변경 사항이 작기 때문에 문제를 검색할 영역이 매우 작기 때문에 이유가 무엇인지 빨리 이해할 수 있습니다.

그리고 출시 후 제품이 무너지더라도 지속적 통합을 실행하면 변경 사항이 작기 때문에 조치를 취하는 것이 훨씬 쉽습니다. 예, 이는 계획에 영향을 미칩니다. 이것은 아플 것입니다. 그리고 아마도 이 연습에서 가장 어려운 일은 작업을 세분화하는 데 익숙해지는 것입니다. 즉, 몇 시간 안에 무언가를 수행하고 동시에 검토를 통과할 수 있도록 수행하는 방법입니다. 너가 하나 가지고 있네. 검토는 별도의 고통입니다.

단위 테스트는 통합이 성공했는지, 손상된 부분은 없는지 이해하는 데 도움이 되는 보조자일 뿐입니다. 제 생각에는 이것이 실천의 요점이 아니기 때문에 완전히 필수는 아닙니다.

지속적 통합에 대한 간략한 소개입니다. 이것이 이 연습의 전부입니다. 질문을 받을 준비가 되어 있습니다.

다시 간단히 요약하겠습니다.

• 지속적인 통합은 Jenkins도 아니고 Gitlab도 아닙니다.
• 이것은 도구가 아니며, 가능한 한 자주 코드를 마스터에 병합하는 것이 관행입니다.
• 우리는 미래에 융합으로 인해 발생하는 엄청난 고통을 피하기 위해 이렇게 합니다. 즉, 미래에 더 이상 경험하지 않기 위해 지금 약간의 고통을 경험하는 것입니다. 그게 요점입니다.
• 측면에는 코드를 통한 통신이 있는데 이것을 거의 볼 수 없지만 이것이 또한 설계된 것입니다.

질문

분해되지 않은 작업은 어떻게 해야 하나요?

분해하다. 문제는 무엇입니까? 태스크가 있는데 분해되지 않은 예를 들어주실 수 있나요?

"완전히"라는 단어로 분해할 수 없는 작업이 있습니다. 예를 들어, 매우 깊은 전문 지식이 필요하고 실제로 한 달 안에 해결하여 소화 가능한 결과를 얻을 수 있는 작업이 있습니다.

내가 당신을 올바르게 이해했다면 크고 복잡한 작업이 있는데 그 결과는 한 달 후에야 볼 수 있습니까?

네 맞습니다. 예, 한 달 이내에 결과를 평가할 수 있습니다.

괜찮은. 일반적으로 이는 문제가 되지 않습니다. 왜? 왜냐하면 이 경우 나뭇가지에 대해 이야기할 때 특징이 있는 나뭇가지에 대해 말하는 것이 아니기 때문입니다. 기능은 크고 복잡할 수 있습니다. 이는 많은 구성 요소에 영향을 미칠 수 있습니다. 그리고 아마도 우리는 한 지점에서 그것들을 완전히 할 수 없을 것입니다. 이건 괜찮아. 우리는 이 이야기를 분해하면 됩니다. 기능이 완전히 준비되지 않았다고 해서 해당 코드의 일부 부분을 병합할 수 없다는 의미는 아닙니다. 예를 들어 마이그레이션을 추가했으며 기능 내부에 몇 가지 단계가 있습니다. 마이그레이션을 수행하고 새 방법을 추가하는 단계가 있다고 가정해 보겠습니다. 그리고 이미 이러한 것들을 매일 측정할 수 있습니다.

괜찮은. 그러면 요점은 무엇입니까?

매일 작은 것들을 죽이는 게 무슨 의미가 있나요?

네.

뭔가 깨지면 바로 보입니다. 작은 조각에 뭔가가 망가졌을 경우 고치는 것이 더 쉽습니다. 요점은 지금 작은 조각을 병합하는 것이 몇 주 안에 큰 조각을 병합하는 것보다 훨씬 쉽다는 것입니다. 세 번째 요점은 다른 엔지니어들이 현재 버전의 코드로 작업할 것이라는 점입니다. 그들은 여기에 일부 마이그레이션이 추가된 것을 보게 될 것이며, 그들이 사용하고 싶어할 만한 몇 가지 방법이 나타날 것입니다. 모든 사람이 코드에서 무슨 일이 일어나고 있는지 볼 수 있습니다. 수행은 이 세 가지를 위해서입니다.

감사합니다. 문제가 종료되었습니다!

(Oleg Soroka) 추가해도 될까요? 모든 것이 정확하게 말씀하셨는데, 한 마디만 추가하고 싶습니다.

겠어요 -

지속적 통합을 사용하면 기능이 완전히 준비된 때가 아니라 빌드 중단이 중지되면 코드가 공통 분기로 병합됩니다. 그리고 하루에 원하는 만큼 안전하게 마스터에 전념할 수 있습니다. 두 번째 측면은 어떤 이유로 월별 작업을 최소 XNUMX일 동안 작업으로 나눌 수 없고 약 XNUMX시간 동안 침묵한다면 큰 문제가 있다는 것입니다. 그리고 지속적인 통합이 없다는 사실은 이러한 문제 중 가장 적습니다. 이는 아키텍처와 엔지니어링 관행에 문제가 있음을 의미합니다. 왜냐하면 이것이 연구라고 해도 어쨌든 가설이나 순환의 형태로 공식화되어야 하기 때문입니다.

우리는 성공적인 기업과 뒤처지는 기업을 구별하는 4가지 지표에 대해 이야기했습니다. 이 4가지 지표를 보려면 아직 살아봐야 합니다. 평균 작업을 완료하는 데 한 달이 걸린다면 먼저 이 측정항목에 중점을 둘 것입니다. 먼저 3일로 낮추겠습니다. 그 후 저는 Continuous에 대해 생각하기 시작했습니다.

어떤 작업을 완료하는 데 한 달이 걸리면 일반적으로 엔지니어링 관행에 투자할 필요가 없다고 생각한다는 점을 제가 올바르게 이해했습니까?

지속적인 통합이 있습니다. 그리고 10분 안에 수정 사항을 수정하거나 롤백할 수 있다는 주제가 있습니다. 당신이 그것을 굴렸다고 상상해보십시오. 더욱이 지속적인 배포를 수행하고 이를 프로덕션으로 롤아웃한 후에야 문제가 발생했음을 발견했습니다. 롤백해야 하는데 이미 데이터베이스를 마이그레이션했습니다. 이미 다음 버전의 데이터베이스 스키마가 있고, 일종의 백업도 있었고 거기에 데이터도 기록되었습니다.

그리고 어떤 대안이 있나요? 코드를 롤백하면 업데이트된 데이터베이스에서 더 이상 작동하지 않습니다.

기지는 앞으로만 움직입니다.

엔지니어링 관행이 좋지 않은 사람들은 아마도...에 관한 두꺼운 책도 읽지 않았을 것입니다. 백업은 어떻게 해야 하나요? 백업에서 복원하면 해당 순간에 축적된 데이터가 손실된다는 의미입니다. 예를 들어, 우리는 새 버전의 데이터베이스에 사용자가 등록된 작업을 XNUMX시간 동안 작업했습니다. 구성표가 새 버전에서 작동하지 않기 때문에 이전 백업을 거부하여 이러한 사용자를 잃었습니다. 그리고 그들은 불만족스러워하며 맹세합니다.

지속적인 통합과 지속적인 전달을 지원하는 다양한 방법을 익히려면 작성 방법을 배우는 것만으로는 충분하지 않습니다.... 첫째, 그것들이 많을 수 있으며 실용적이지 않습니다. 게다가 Scientific과 같은 다른 관행도 많이 있습니다. 이런 관행이 있는데, GitHub가 한때 대중화하기도 했습니다. 이는 이전 코드와 새 코드가 동시에 실행되는 경우입니다. 미완성 기능을 만들지만 함수 또는 Rest API로 일부 값을 반환할 수 있는 경우입니다. 새 코드와 이전 코드를 모두 실행하고 차이점을 비교합니다. 차이가 있으면 이 이벤트를 기록합니다. 이렇게 하면 특정 시간 동안 두 기능 사이에 불일치가 없었던 경우 이전 기능 위에 새로운 기능을 출시할 준비가 되었음을 알 수 있습니다.

그러한 관행은 수백 가지가 있습니다. 트랜스베이스 개발부터 시작하는 것이 좋습니다. 그녀는 지속적인 통합에 100% 만족하지는 않지만 관행은 동일하며 하나가 없으면 잘 살 수 없습니다.

사례를 볼 수 있는 사례로 트랜스베이스 개발을 제시했습니까? 아니면 사람들이 트랜스베이스 개발을 시작하도록 제안했습니까?

사용해 보세요. 사용할 수 없기 때문입니다. 그것들을 사용하려면 많이 읽어야 합니다. 그리고 어떤 사람이 "한 달이 걸리는 기능을 어떻게 해야 합니까?"라고 묻는다면, 이는 그가 트랜스베이스 개발에 대해 읽지 않았다는 뜻입니다. 아직은 추천하고 싶지 않습니다. 대규모 작업을 구조적으로 올바르게 작은 작업으로 나누는 방법에 대한 주제에만 집중하는 것이 좋습니다. 이것이 분해의 본질이다.

분해는 건축가의 도구 중 하나입니다. 먼저 분석을 한 다음 분해, 합성, 통합을 수행합니다. 그리고 이것이 우리에게 모든 일이 일어나는 방식입니다. 그리고 우리는 여전히 분해를 통해 지속적인 통합으로 성장해야 합니다. 첫 번째 단계에서 질문이 발생하며 이미 네 번째 단계에 대해 이야기하고 있습니다. 즉, 통합을 더 자주 수행할수록 좋습니다. 아직은 시기상조이므로 먼저 모노리스를 잘라내는 것이 좋을 것 같습니다.

일부 다이어그램에는 여러 개의 화살표와 사각형을 그려야 합니다. 이제 새 애플리케이션의 아키텍처 다이어그램을 표시하고 그 안에 애플리케이션에 대한 녹색 버튼이 있는 사각형 하나를 표시할 것이라고 말할 수는 없습니다. 어쨌든 더 많은 사각형과 화살표가 있을 것입니다. 내가 본 모든 다이어그램에는 둘 이상의 다이어그램이 있었습니다. 그리고 그래픽 표현 수준에서도 분해가 이미 진행되고 있습니다. 따라서 정사각형은 독립될 수 있습니다. 그렇지 않다면 건축가에게 큰 질문이 있습니다.

채팅에서 다음과 같은 질문이 있습니다. "리뷰가 필수이고 시간이 오래 걸리면 하루 이상 걸릴 수도 있나요?"

연습에 문제가 있습니다. 검토는 하루 이상 지속되어서는 안 됩니다. 이것은 이전 질문과 동일한 이야기이지만 조금 더 부드럽습니다. 리뷰가 하루 동안 계속된다면 이 리뷰는 매우 큰 변화를 가져올 가능성이 높습니다. 즉, 크기를 더 작게 만들어야 한다는 뜻입니다. 올렉이 추천한 트랜스베이스 개발에는 지속적 검토라는 이야기가 있다. 그녀의 생각은 우리가 지속적으로 한 번에 조금씩 병합하려고 노력하기 때문에 의도적으로 이렇게 작은 풀 요청을 한다는 것입니다. 따라서 풀 요청은 하나의 추상화 또는 10줄을 변경합니다. 이 검토 덕분에 몇 분 정도 소요되었습니다.

검토에 하루 이상이 소요된다면 문제가 있는 것입니다. 첫째, 아키텍처에 몇 가지 문제가 있을 수 있습니다. 또는 예를 들어 1줄에 달하는 큰 코드 조각입니다. 또는 아키텍처가 너무 복잡해서 사람이 이해할 수 없는 경우도 있습니다. 이것은 약간 옆으로 치닫는 문제이지만 해결해야 할 문제이기도 합니다. 아마도 리뷰가 전혀 필요하지 않을 것입니다. 우리도 이것에 대해 생각해 볼 필요가 있습니다. 검토는 속도를 늦추는 것입니다. 일반적으로 장점이 있지만 왜 그렇게 하는지 이해해야 합니다. 정보를 빠르게 전달하기 위한 방법인가요, 내부적으로 기준을 세우기 위한 방법인가요? 왜 이것이 필요합니까? 검토를 매우 신속하게 완료하거나 완전히 취소해야 하기 때문입니다. 그것은 트랜스베이스 개발과 같습니다. 이야기는 매우 아름답지만 성숙한 남성에게만 해당됩니다.

4가지 지표와 관련하여 이것이 어떤 결과를 가져오는지 이해하기 위해 이를 제거하는 것이 좋습니다. 숫자를 보고, 사진을 보고, 모든 것이 얼마나 나쁜지 보십시오.

(Dmitry) 저는 이에 대해 귀하와 논의할 준비가 되어 있습니다. 숫자와 지표는 모두 훌륭하고 실천도 훌륭합니다. 하지만 비즈니스에 필요한지 여부를 이해해야 합니다. 그런 변화의 속도가 필요하지 않은 기업이 있습니다. 나는 15분마다 변화가 이루어질 수 없는 회사를 알고 있습니다. 그리고 그들이 너무 나쁘기 때문이 아닙니다. 이것은 그러한 수명주기입니다. 그리고 브랜치 기능, 토글 기능을 만들기 위해서는 깊은 지식이 필요합니다.

복잡해요. 토글 기능에 대한 이야기를 더 자세히 읽고 싶다면 적극 추천합니다 https://trunkbaseddevelopment.com/. 그리고 토글 기능에 대한 Martin Fowler의 멋진 기사가 있습니다. 어떤 유형이 있는지, 수명 주기 등이 있습니다. 토글 기능은 복잡합니다.

그리고 당신은 "Jenkins가 필요한가, 필요하지 않은가?"라는 질문에 아직 대답하지 않았습니다.

Jenkins는 실제로 어떤 경우에도 필요하지 않습니다. 하지만 Jenkins, Gitlab과 같은 도구는 여러분에게 편리함을 가져다 줄 것입니다. 어셈블리가 조립되었는지 또는 조립되지 않았는지 확인할 수 있습니다. 그들은 당신을 도울 수는 있지만 연습을 제공하지는 않습니다. 그들은 당신에게 서클만 제공할 수 있습니다 - 알았어, 알았어가 아니야. 그런 다음 테스트도 작성하면 테스트가 없으면 거의 의미가 없기 때문입니다. 따라서 더 편리하기 때문에 필요하지만 일반적으로 그것 없이도 살 수 있으며 많이 잃지 않을 것입니다.

즉, 실천이 있다면 그것이 필요하지 않다는 뜻인가요?

좋아요. Jez Humble 테스트를 추천합니다. 나는 마지막 요점에 대해 양면적인 태도를 가지고 있습니다. 그러나 일반적으로 세 가지가 있다면 지속적으로 병합하고, 마스터에서 커밋에 대해 테스트를 실행하고, 마스터에서 빌드를 빠르게 수정하면 아마도 다른 것이 필요하지 않을 것입니다.

참가자분들의 질문을 기다리다가 질문이 있습니다. 우리는 방금 제품 코드에 대해 이야기하고 있었습니다. 인프라 코드에 사용해 보셨나요? 동일한 코드입니까, 동일한 원칙과 동일한 라이프사이클을 가지고 있습니까, 아니면 다른 라이프사이클과 원칙이 있습니까? 일반적으로 모든 사람이 지속적인 통합 및 개발에 대해 이야기할 때 인프라 코드도 있다는 사실을 모두가 잊어버립니다. 그리고 최근에는 그런 일이 점점 더 많아졌습니다. 그리고 이 모든 규칙을 거기까지 가져와야 할까요?

꼭 그래야 하는 것은 아니지만, 같은 방식으로 삶을 더 쉽게 만들어 주기 때문에 좋을 것입니다. bash 스크립트가 아닌 코드로 작업하자마자 일반 코드가 있습니다.

중지, 중지, bash 스크립트도 코드입니다. 내 옛 사랑을 건드리지 마세요.

알았어, 네 기억은 짓밟지 않을게. 나는 bash를 개인적으로 싫어합니다. 항상 추악하고 무섭습니다. 그리고 예측할 수 없이 깨지는 경우가 많기 때문에 마음에 들지 않습니다. 하지만 좋습니다. bash 코드가 있다고 가정해 보겠습니다. 아마도 제가 정말 이해하지 못하는 것일 수도 있고 거기에는 일반적인 테스트 프레임워크가 있을 수도 있습니다. 나는 단지 모른다. 그리고 우리는 동일한 이점을 얻습니다.

코드형 인프라로 작업하자마자 개발자와 동일한 문제가 발생합니다. 몇 달 전, 동료가 나에게 bash에서 1줄에 대한 풀 요청을 보낸 상황에 직면했습니다. 그리고 당신은 000시간 동안 리뷰에 시간을 보냅니다. 동일한 문제가 발생합니다. 아직은 코드입니다. 그리고 그것은 여전히 ​​​​협력입니다. 예를 들어, 풀 요청에 갇히고 동일한 bash에서 동일한 병합 충돌을 해결하고 있다는 사실에 갇히게 됩니다.

나는 지금 가장 아름다운 인프라 프로그래밍에 관한 이 모든 것을 매우 적극적으로 살펴보고 있습니다. 이제 Pulumi를 인프라에 도입했습니다. 이것은 가장 순수한 형태의 프로그래밍입니다. 프로그래밍 언어의 모든 기능을 갖추고 있기 때문에 훨씬 더 좋습니다. 즉, 동일한 if를 사용하여 갑자기 아름다운 토글을 만들었고 모든 것이 정상입니다. 즉, 내 변경 사항이 이미 마스터에 있습니다. 누구나 이미 그를 볼 수 있습니다. 다른 엔지니어들도 알고 있습니다. 이미 거기에 뭔가 영향을 미쳤습니다. 그러나 모든 인프라에 대해 활성화되지는 않았습니다. 예를 들어 내 테스트 벤치에서는 켜졌습니다. 따라서 귀하의 질문에 다시 답변하는 것이 필요합니다. 같은 방식으로 코드를 작업하는 엔지니어로서 우리의 삶이 더 쉬워집니다.

다른 사람이 질문이 있다면?

질문이 있습니다. 나는 Oleg와 토론을 계속하고 싶습니다. 일반적으로 나는 당신이 옳다고 생각합니다. 작업을 완료하는 데 한 달이 걸리면 아키텍처에 문제가 있고 분석, 분해, 계획 등에 문제가 있는 것입니다. 지속적인 통합에 따라 라이브를 시도하면 다른 곳에서는 벗어날 수 없기 때문에 계획을 통해 고통을 바로잡기 시작할 것입니다.

(올렉) 네, 맞습니다. 이 관행은 문화를 바꾸는 다른 심각한 관행과 노력 면에서 비슷합니다. 가장 극복하기 어려운 것은 습관, 특히 나쁜 습관입니다. 그리고 이 관행을 구현하려면 개발자, 경영진, 생산 관리자 등 주변 사람들의 습관에 심각한 변화가 필요하며 놀라움이 여러분을 기다립니다.

어떤 놀라움이 있을 수 있을까요? 더 자주 통합하기로 결정했다고 가정해 보겠습니다. 그리고 통합과 관련된 다른 것(예: 아티팩트)도 있습니다. 예를 들어, 귀하의 회사에는 모든 아티팩트가 일종의 아티팩트 저장 시스템에서 어떤 방식으로든 설명되어야 한다는 정책이 있습니다. 그리고 시간이 좀 걸립니다. 릴리스 관리자로서 이 아티팩트를 테스트하여 프로덕션 환경에서 릴리스할 준비가 되었는지 확인하는 확인란을 선택해야 합니다. 5~10~15분이 소요되지만 일주일에 한 번 레이아웃을 수행한다면 일주일에 한 번 XNUMX분을 소비하는 것은 작은 세금입니다.

지속적 통합을 하루에 10번 수행한다면 10번에 30분을 곱해야 합니다. 그리고 이는 이 릴리스 관리자의 작업 시간을 초과합니다. 그는 단지 그 일을 하는 것에 지쳤을 뿐입니다. 일부 관행에는 고정 비용이 있습니다. 그게 다야.

그리고 더 이상 그런 쓰레기를 만들지 않도록 이 규칙을 취소해야 합니다. 즉, 무언가에 해당하는 학위를 수동으로 할당하지 않습니다. 자동화된 준비 상태 테스트 세트에 전적으로 의존하고 있습니다.

그리고 상사가 서명하기 위해 누군가의 증거가 필요한 경우 Vasya가 허용한다고 말하지 않고는 생산에 들어갈 수 없습니다. 이 모든 말도 안되는 소리는 실무자를 방해합니다. 왜냐하면 세금과 관련된 활동이 있으면 모든 것이 100배 증가하기 때문입니다. 따라서 이러한 변화는 모든 사람이 기쁨으로 환영하지 않는 경우가 많습니다. 사람의 습관은 바꾸기 어렵기 때문이죠.

사람이 일상적인 일을 할 때, 그는 거의 아무 생각 없이 그 일을 합니다. 그녀의 인지부하는 XNUMX입니다. 그는 단지 그것을 가지고 놀고 있고, 이미 그의 머리 속에 체크리스트가 있고, 그 일을 수천 번이나 해냈습니다. 그리고 당신이 그에게 와서 “이 연습을 취소하고 월요일부터 새로운 연습을 시작하자”라고 말하면 그에게 그것은 강력한 인지 부하가 ​​됩니다. 그리고 그것은 모든 사람에게 동시에 다가옵니다.

따라서 가장 간단한 것은 모든 사람이이 사치를 감당할 수는 없지만 이것이 제가 항상하는 일이며 다음은 다음과 같습니다. 새 프로젝트가 시작되면 일반적으로 테스트되지 않은 모든 사례가 즉시 이 프로젝트에 채워집니다. 프로젝트가 초기 단계이긴 하지만 실제로 위험을 감수하지는 않습니다. 아직 Prod도 없고 파괴할 것도 없습니다. 따라서 훈련용으로 사용할 수 있습니다. 이 접근 방식은 효과적입니다. 그러나 모든 회사가 그러한 프로젝트를 자주 시작할 기회를 갖는 것은 아닙니다. 이것도 조금 이상하지만 이제 완전한 디지털 혁신이 이루어졌기 때문에 모두가 경쟁사를 따라잡기 위해 실험을 시작해야 합니다.

여기서 당신은 먼저 무엇을 해야 하는지 이해해야 한다는 결론에 도달합니다. 세상은 이상적이지 않으며 자극도 이상적이지 않습니다.

예, 이러한 것들은 서로 연결되어 있습니다.

기업은 또한 이런 식으로 가야 한다는 것을 항상 이해하는 것은 아닙니다.

전혀 변화가 불가능한 상황이 발생합니다. 팀의 부담이 더 커진 상황이다. 팀은 이미 지쳐있습니다. 그녀는 어떤 실험에도 여가 시간이 없습니다. 그들은 아침부터 저녁까지 기능을 연구합니다. 그리고 관리 기능은 점점 더 적어지고 있습니다. 점점 더 많은 것이 필요합니다. 이런 상황에서는 전혀 변화가 불가능합니다. 팀에서는 내일도 어제와 똑같이 할 것이며 기능을 조금 더 만들면 된다는 말만 들었습니다. 이러한 의미에서 어떤 관행으로의 전환도 불가능합니다. 도끼를 갈 시간이 없어서 나무를 잘라야해서 무딘 도끼로 자르는 전형적인 상황입니다. 여기에는 간단한 팁이 없습니다.

(Dmitry) 채팅에서 설명을 읽어보겠습니다. “하지만 우리는 다양한 수준에서 많은 테스트 범위가 필요합니다. 테스트에 얼마나 많은 시간이 할당되나요? 가격도 조금 비싸고 시간도 많이 걸립니다.”

(Oleg) 이것은 고전적인 오해입니다. 자신감을 가지려면 충분한 테스트가 있어야 합니다. 지속적인 통합은 먼저 100% 테스트가 완료된 다음에만 이 방법을 적용하기 시작하는 것이 아닙니다. 지속적인 통합은 눈으로 보는 각각의 변화가 테스트 없이도 그것이 무엇인가 깨질지 아닐지 이해할 수 있을 정도로 명백하기 때문에 인지 부하를 줄여줍니다. 변경 사항이 적기 때문에 머리 속으로 빠르게 테스트할 수 있습니다. 수동 테스터만 있어도 더 쉽습니다. 당신은 밖으로 나가서 이렇게 말했습니다. "보세요. 깨진 것이 있나요?" 확인해보니 “아뇨, 깨진 것은 하나도 없습니다.”라고 하더군요. 테스터는 어디를 봐야 할지 알고 있기 때문입니다. 하나의 코드와 연관된 하나의 커밋이 있습니다. 그리고 이것은 특정 행동에 의해 악용됩니다.

물론 여기 당신은 장식되었습니다.

(드미트리) 나는 여기에 동의하지 않습니다. 이러한 상황을 방지할 수 있는 테스트 중심 개발 방법이 있습니다.

(올렉) 글쎄요, 아직 그 지점까지는 도달하지 못했습니다. 첫 번째 환상은 테스트를 100% 작성해야 하거나 지속적 통합을 전혀 수행할 필요가 없다는 것입니다. 사실이 아닙니다. 이는 두 가지 병렬 관행입니다. 그리고 그들은 직접적으로 의존하지 않습니다. 테스트 범위는 최적이어야 합니다. 최적 - 이는 커밋 후 마스터가 남아 있는 마스터의 품질로 인해 금요일 저녁에 술취한 "배포" 버튼을 자신 있게 누를 수 있다는 것을 의미합니다. 이것을 어떻게 달성합니까? 검토를 통해, 취재를 통해, 좋은 모니터링을 통해.

좋은 모니터링은 테스트와 구별할 수 없습니다. 사전 프로덕션에서 테스트를 한 번 실행하면 모든 사용자 스크립트를 한 번만 확인하면 끝입니다. 그리고 무한 루프에서 실행하는 경우 이는 충돌 여부에 관계없이 모든 것을 끝없이 테스트하는 배포된 모니터링 시스템입니다. 이 경우 유일한 차이점은 한 번 수행되는지, 두 번 수행되는지입니다. 아주 좋은 테스트 세트... 끝없이 실행되는 것은 모니터링입니다. 그리고 제대로 된 모니터링은 이래야 합니다.

따라서 금요일 저녁에 준비하고 집에 갈 때 이 상태를 정확히 어떻게 달성할 것인지는 또 다른 질문입니다. 어쩌면 당신은 대담한 쓰레기일지도 모릅니다.

지속적인 통합으로 조금 돌아가 보겠습니다. 우리는 약간 다른 복잡한 관행에 직면했습니다.

그리고 두 번째 환상은 MVP가 신속하게 완료되어야 하므로 테스트가 전혀 필요하지 않다는 것입니다. 그런 식으로는 확실히 아닙니다. 사실 MVP에서 사용자 스토리를 작성할 때 공 위에서 개발할 수 있습니다. 즉, 일종의 사용자 스토리가 있다는 것을 듣고 즉시 실행하여 코딩하거나 TDD를 사용하여 작업할 수 있습니다. 그리고 TDD에 따르면 실습에서 알 수 있듯이 시간이 더 오래 걸리지 않습니다. 즉, 테스트는 부작용입니다. TDD의 실천은 테스트에 관한 것이 아닙니다. 테스트 주도 개발(Test Driven Development)이라고 불리는 것에도 불구하고 그것은 전혀 테스트에 관한 것이 아닙니다. 이것은 또한 오히려 건축적인 접근 방식입니다. 꼭 필요한 것만 쓰고, 필요하지 않은 것은 쓰지 않는 접근 방식입니다. 이는 애플리케이션 아키텍처 생성 측면에서 생각의 다음 반복에 집중하는 관행입니다.

그러므로 이러한 환상을 없애는 것은 그리 쉽지 않습니다. MVP와 테스트는 서로 모순되지 않습니다. 심지어 오히려 반대로 TDD 연습을 사용하여 MVP를 수행하면 전혀 연습하지 않고 공 위에서 수행하는 것보다 더 좋고 빠르게 수행할 수 있습니다.

이것은 매우 명확하지 않고 복잡한 아이디어입니다. 이제 더 많은 테스트를 작성하고 동시에 더 빠른 작업을 수행할 것이라는 말을 들으면 완전히 부적절하게 들립니다.

(Dmitry) 여기 많은 사람들은 MVP를 부를 때 너무 게으른 나머지 정상적인 내용을 작성하지 않습니다. 그리고 이것들은 여전히 ​​​​다른 것입니다. MVP를 작동하지 않는 나쁜 것으로 바꿀 필요는 없습니다.

예, 예, 당신 말이 맞아요.

그리고 갑자기 프로덕션에서 MVP가 되었습니다.

영원히.

그리고 TDD는 테스트를 작성하고 더 많은 작업을 수행하는 것 같다는 말을 들으면 매우 이상하게 들립니다. 매우 이상하게 들리지만 실제로는 이렇게 하면 더 빠르고 예뻐집니다. 테스트를 작성할 때 어떤 코드가 호출될지, 어떻게 호출될지, 그리고 코드에서 기대하는 동작이 무엇인지에 대해 이미 머리 속으로 많이 생각하게 됩니다. 내가 어떤 함수를 작성했고 그것이 어떤 일을 한다고만 말하는 것이 아닙니다. 처음에 당신은 그녀가 이러저러한 조건을 가지고 있고, 이러저러한 방식으로 부름을 받을 것이라고 생각했습니다. 이를 테스트로 다루고 이를 통해 인터페이스가 코드 내부에서 어떻게 보이는지 이해합니다. 이는 건축에 큰 영향을 미칩니다. 먼저 코드를 테스트하는 방법을 이해한 다음 작성하기 때문에 코드는 자동으로 모듈화됩니다.

TDD를 하면서 나에게 일어난 일은 내가 아직 Ruby 프로그래머였을 때 어느 시점에 Ruby 멘토를 고용했다는 것입니다. 그리고 그는 "TDD에 따라 해보자"고 말합니다. 나는 생각했다: "젠장, 이제 뭔가를 더 써야 해." 그리고 우리는 XNUMX주 안에 TDD를 사용하여 Python으로 모든 작업 코드를 작성하기로 합의했습니다. XNUMX주 후에 나는 돌아가고 싶지 않다는 것을 깨달았습니다. 이것을 모든 곳에 적용하려고 XNUMX주 동안 노력한 후에는 생각하는 것조차 얼마나 쉬워졌는지 깨닫게 됩니다. 하지만 이것이 명확하지 않기 때문에 TDD가 어렵고 시간이 많이 걸리며 불필요하다는 느낌이 든다면 단 XNUMX주만 TDD를 고수해 보시기를 모든 사람에게 권장합니다. 나에겐 두 개면 충분했다.

(Dmitry) 이 아이디어를 인프라 운영의 관점에서 확장할 수 있습니다. 새로운 것을 출시하기 전에 모니터링을 한 다음 출시합니다. 이 경우 모니터링은 우리에게 일반적인 테스트가 됩니다. 그리고 모니터링을 통한 발전이 있습니다. 그런데 거의 다들 길다, 게으르다, 임시 초안을 만들었다고 하더군요. 정상적인 모니터링을 했다면 CI 시스템의 상태를 파악하게 됩니다. 그리고 CI 시스템에는 모니터링이 많아요. 우리는 시스템의 상태를 이해하고 그 내부에 무엇이 있는지 이해합니다. 그리고 개발 과정에서는 시스템이 원하는 상태에 도달할 수 있도록 만들어나가고 있을 뿐입니다.

이러한 관행은 오랫동안 알려져 왔습니다. 우리는 약 4년 전에 이에 대해 논의했습니다. 하지만 4년 동안 거의 아무것도 변하지 않았습니다.

그러나 이 점에 대해 나는 공식적인 논의를 중단할 것을 제안합니다.

비디오(미디어 요소로 삽입되었지만 어떤 이유로 작동하지 않음):

https://youtu.be/zZ3qXVN3Oic

출처 : habr.com