개발자를 위한 최고의 DevOps 사례. 안톤 보이코 (2017)

보고서에서는 일부 DevOps 관행에 대해 설명하지만 개발자의 관점에서 설명합니다. 일반적으로 DevOps에 합류하는 모든 엔지니어는 이미 수년간의 관리 경험을 갖고 있습니다. 그러나 이것이 여기에 개발자를 위한 자리가 없다는 것을 의미하지는 않습니다. 개발자들은 "오늘의 다음 긴급 버그"를 수정하느라 바쁘고 DevOps 분야를 잠깐 살펴볼 시간조차 없는 경우가 많습니다. 저자의 이해에 따르면 DevOps는 우선 상식입니다. 둘째, 더 효과적으로 일할 수 있는 기회이다. 귀하가 개발자이고 상식이 있으며 팀 플레이어로서 보다 효율적이기를 원한다면 이 보고서가 귀하를 위한 것입니다.

제 소개를 하자면, 이 자리에 저를 모르는 분들도 계시다는 사실을 충분히 인정합니다. 제 이름은 Anton Boyko이고 Microsoft Azure MVP입니다. MVP란 무엇입니까? 이것이 모델-뷰-프레젠터입니다. Model-View-Presenter가 바로 나입니다.

또한 저는 현재 Ciklum에서 솔루션 아키텍트 직책을 맡고 있습니다. 그리고 최근에 저는 이렇게 아름다운 도메인을 구입했고, 주로 프레젠테이션에서 보여주던 이메일을 업데이트했습니다. me [dog] byokoant.pro로 저에게 편지를 보내실 수 있습니다. 질문이 있으면 이메일을 보내주세요. 나는 보통 대답합니다. 유일한 것은 정치와 종교라는 두 가지 주제와 관련된 질문을 이메일로 받고 싶지 않다는 것입니다. 다른 모든 사항에 대해서는 이메일로 저에게 편지를 보내실 수 있습니다. 시간이 좀 지나면 답변해 드리겠습니다.

나 자신에 대한 몇 마디:

• 저는 이 분야에 종사한 지 벌써 10년이 되었습니다.
• 저는 마이크로소프트에서 일했어요.
• 저는 2014년에 설립된 우크라이나 Azure 커뮤니티의 창시자입니다. 그리고 우리는 아직도 그것을 갖고 있고 개발 중입니다.
• 저는 또한 우리가 우크라이나에서 주최하고 있는 Azure 컨퍼런스 창립자의 아버지이기도 합니다.
• 저는 또한 키예프에서 Global Azure Bootcamp를 조직하는 일을 돕고 있습니다.
• 앞서 말했듯이 저는 Microsoft Azure MVP입니다.
• 나는 회의에서 꽤 자주 연설합니다. 저는 컨퍼런스에서 연설하는 것을 정말 좋아합니다. 지난 40년 동안 약 XNUMX회 정도 공연을 했습니다. 우크라이나, 벨로루시, 폴란드, 불가리아, 스웨덴, 덴마크, 네덜란드, 스페인을 지나가거나 유럽의 다른 국가를 주고받는 경우 스트림에 클라우드 테마가 있는 컨퍼런스에 가면 연사 목록에서 저를 보실 수 있습니다.
• 저도 스타트렉 팬이에요.

의제에 대해 조금 이야기 해 봅시다. 우리의 의제는 매우 간단합니다.

• DevOps가 무엇인지 이야기해보겠습니다. 이것이 왜 중요한지 이야기해 봅시다. 이전에는 DevOps가 이력서에 적으면 즉시 급여 $500 이상을 받는 키워드였습니다. 이제 급여를 +500달러 받으려면 이력서에 블록체인 등을 작성해야 합니다.
• 그런 다음 이것이 무엇인지 조금 이해하면 DevOps 관행이 무엇인지 이야기하겠습니다. 그러나 일반적인 DevOps의 맥락은 아니지만 개발자가 관심을 가질 수 있는 DevOps 관행에 관한 것입니다. 왜 그들이 당신에게 관심을 가질 수 있는지 말씀드리겠습니다. 왜 이것을 해야 하는지, 그리고 이것이 통증을 줄이는 데 어떻게 도움이 되는지 말씀드리겠습니다.

많은 사람들이 보여주는 전통 그림. 이것은 많은 프로젝트에서 일어나는 일입니다. 이때는 소프트웨어를 지원하는 개발 및 운영 부서가 있는 시기입니다. 그리고 이 부서들은 서로 의사소통을 하지 않습니다.

아마도 DevOps와 운영 부서에서는 그렇게 명확하게 느낄 수 없었다면 Dev와 QA 부서에 비유해 볼 수 있을 것입니다. 소프트웨어를 개발하는 사람도 있고, 개발자 입장에서 나쁜 QA 사람도 있습니다. 예를 들어, 내가 멋진 코드를 저장소에 커밋했는데 거기에 앉아 있는 어떤 악당이 이 코드를 나에게 돌려주고 당신의 코드가 나쁘다고 말합니다.

이 모든 일은 사람들이 서로 의사소통을 하지 않기 때문에 발생합니다. 그리고 그들은 오해의 벽을 넘어 서로에게 패키지와 애플리케이션을 던지고 뭔가를 하려고 합니다.

DevOps 문화가 파괴하도록 설계된 것은 바로 이 벽입니다. 사람들이 서로 의사소통하도록 강요하고 최소한 프로젝트에서 다른 사람들이 하는 일과 그들의 작업이 왜 중요한지 이해하도록 합니다.

DevOps에 대해 이야기할 때 누군가는 DevOps가 프로젝트에 지속적인 통합이 필요한 때라고 말할 것입니다. 누군가는 DevOps가 프로젝트가 "코드로서의 인프라" 방식을 구현하는 것이라고 말할 것입니다. 누군가 DevOps의 첫 번째 단계는 기능 분기, 기능 플래그라고 말할 것입니다.

본질적으로 이것은 그 자체로 모두 사실입니다. 그러나 이것은 우리가 가지고 있는 궁극적인 관행일 뿐입니다. 이러한 사례로 넘어가기 전에 회사의 프로젝트에서 Dev-Ops 방법론을 구현하는 3단계를 보여주는 이 슬라이드를 살펴보는 것이 좋습니다.

이 슬라이드에는 두 번째 비공식 이름도 있습니다. 온라인으로 검색하여 DevOps의 3총사가 무엇인지 알아볼 수 있습니다. 이 기사를 찾을 가능성이 있습니다. 왜 삼총사인가? 아래에는 사람, 프로세스, 제품 등이 적혀 있습니다. PPP - 포르토스, 포르토스, 포르토스. DevOps의 3총사는 다음과 같습니다. 이 기사에서는 이것이 왜 중요하고 무엇이 수반되는지 더 자세히 설명합니다.

DevOps 문화 구현을 시작할 때 다음 순서로 구현하는 것이 매우 중요합니다.

처음에는 사람들과 대화를 해야 합니다. 그리고 그것이 무엇인지, 그리고 그것이 어떻게 혜택을 얻을 수 있는지 사람들에게 설명해야 합니다.

우리 회의는 DotNet Fest라고 불립니다. 그리고 주최측에서 말했듯이 이곳에는 주로 개발자 청중을 초대했기 때문에 홀에있는 대부분의 사람들이 개발에 참여하기를 바랍니다.

우리는 사람들에 대해 이야기할 것이고, 개발자들이 매일 무엇을 하고 싶어하는지에 대해 이야기할 것입니다. 그들이 가장 원하는 것은 무엇입니까? 그들은 새로운 코드를 작성하고, 새로운 프레임워크를 사용하고, 새로운 기능을 만들고 싶어합니다. 개발자가 가장 원하지 않는 것은 무엇입니까? 오래된 버그를 수정하세요. 나는 당신이 내 말에 동의하기를 바랍니다. 이것이 개발자가 원하는 것입니다. 그들은 새로운 기능을 작성하고 싶어하지만 버그를 수정하고 싶어하지 않습니다.

특정 개발자가 생성하는 버그의 수는 팔이 얼마나 곧은지, 팔이 엉덩이 주머니가 아닌 어깨에서 얼마나 자라는지에 따라 달라집니다. 하지만 그럼에도 불구하고 대규모 프로젝트를 진행하다 보면 때로는 모든 것을 추적하는 것이 불가능할 때가 있으므로 보다 안정적이고 고품질의 코드를 작성하는 데 도움이 되는 몇 가지 접근 방식을 사용하는 것이 좋을 것입니다.

QA가 가장 원하는 것은 무엇입니까? 복도에 있는지는 모르겠습니다. QA를 받아본 적이 없기 때문에 QA를 원한다고 말하기는 어렵습니다. 그리고 그 사람들에게 화를 내지 마십시오. 나는 결코 그렇게하지 않기를 바랍니다. 하지만 나는 그들의 일을 무의미하고 쓸모없다고 생각하기 때문이 아니라, 나 자신이 이 일을 효율적으로 할 수 있는 사람이라고 생각하지 않기 때문에 시도조차 하지 않을 것이다. 하지만 내가 이해한 바에 따르면 QA가 가장 좋아하지 않는 것은 아침에 일을 하고 일종의 회귀 테스트를 지속적으로 실행하며 3스프린트 전에 개발자에게 보고한 것과 동일한 버그를 밟고 다음과 같이 말하는 것입니다. , Monsieur D 'Artagnan, 이 버그를 수정하세요.' 그러자 Monsieur D'Artagnan이 그에게 대답했습니다. "예, 예, 예, 이미 고쳤습니다." 그리고 어떻게 해서 버그 하나를 고치고 그 과정에서 5개를 만들게 됐나요?

프로덕션에서 이 솔루션을 지원하는 사람들은 이 솔루션이 버그 없이 작동하여 모든 일반 사람들이 바에 갈 때 매주 금요일에 서버를 재부팅할 필요가 없기를 원합니다. 개발자는 금요일에 배포하고 관리자는 토요일까지 이 배포를 준비하고 수정하려고 노력합니다.

그리고 사람들에게 동일한 문제를 해결하는 것이 목표라고 설명하면 프로세스를 공식화할 수 있습니다. 그것은 매우 중요합니다. 왜? 왜냐하면 우리가 "공식화"라고 말할 때 최소한 냅킨 어딘가에 프로세스가 어떻게 진행되는지 설명하는 것이 중요하기 때문입니다. 예를 들어 QA 환경이나 프로덕션 환경에 배포하는 경우 항상 이 순서대로 발생한다는 점을 이해해야 합니다. 이 단계에서는 자동 단위 테스트 및 UI 테스트 등을 실행합니다. 배포 후에는 배포가 잘 되었는지, 잘 안 되었는지를 확인합니다. 하지만 프로덕션 환경에 배포할 때 반복해서 반복해야 하는 작업의 명확한 목록이 이미 있습니다.

그리고 프로세스가 공식화될 때만 이러한 프로세스를 자동화하는 데 도움이 되는 제품을 선택하기 시작하세요.

불행하게도 저는 이런 일이 거꾸로 일어나는 것을 자주 봅니다. 누군가 "DevOps"라는 단어를 듣자마자 Jenkins 설치를 즉시 제안합니다. Jenkins를 설치하자마자 DevOps를 갖게 될 것이라고 믿기 때문입니다. 그들은 Jenkins를 설치하고, Jenkins 웹사이트에서 "How to" 기사를 읽고, 이 How to 기사에 프로세스를 집어넣으려고 시도한 다음, 사람들에게 다가와서 사람들을 구부리며 책에서는 이렇게 해야 한다고 말했습니다. 그래서 우리는 이렇게 합니다.

Jenkins가 나쁜 도구라는 것은 아닙니다. 어떤 식으로든 그런 말을 하려는 건 아니다. 하지만 이것은 제품 중 하나일 뿐입니다. 그리고 어떤 제품을 사용할지는 마지막 결정이어야 하며 결코 첫 번째 결정이 아닙니다. 귀하의 제품은 문화와 접근 방식의 구현에 의해 주도되어서는 안됩니다. 이것은 이해하는 것이 매우 중요합니다. 이것이 바로 제가 이 슬라이드에 많은 시간을 할애하고 이 모든 것을 오랫동안 설명하는 이유입니다.

일반적인 DevOps 관행에 대해 이야기해 보겠습니다. 그들은 무엇인가? 차이점은 무엇입니까? 어떻게 입어보나요? 왜 중요한가요?

여러분이 들어보셨을 첫 번째 사례는 지속적인 통합(Continuous Integration)입니다. 프로젝트에 참여하는 누군가가 CI(지속적 통합)를 갖고 있을 수도 있습니다.

가장 큰 문제는 내가 사람에게 “프로젝트에 CI가 있나요?”라고 물을 때 가장 자주 발생한다는 것입니다. 그리고 그는 "예"라고 말합니다. 그런 다음 그가 무엇을 하는지 물었을 때 그는 나에게 전체 자동화 프로세스를 절대적으로 설명했습니다. 이것은 전적으로 사실이 아닙니다.

실제로 CI의 실행은 다양한 사람들이 작성하는 코드를 일종의 단일 코드 기반으로 통합하는 것을 목표로 합니다. 그게 다야.

CI와 함께 일반적으로 지속적인 배포, 릴리스 관리와 같은 다른 방법이 있지만 이에 대해서는 나중에 설명하겠습니다.

CI 자체는 다양한 사람들이 코드를 작성하며 이 코드는 단일 코드 기반으로 지속적으로 통합되어야 함을 알려줍니다.

이것이 우리에게 무엇을 제공하며 왜 중요한가요? DotNet이 있다면 좋습니다. 컴파일된 언어이므로 애플리케이션을 컴파일할 수 있습니다. 컴파일되면 이는 이미 좋은 신호입니다. 이는 아직 아무 의미도 없지만 최소한 컴파일할 수 있다는 첫 번째 좋은 신호입니다.

그런 다음 별도의 연습인 몇 가지 테스트를 실행할 수 있습니다. 테스트는 모두 녹색입니다. 이는 두 번째 좋은 신호입니다. 그러나 다시 말하지만 이것은 아무 의미가 없습니다.

그런데 왜 이런 일을 하겠습니까? 오늘 제가 이야기할 모든 관행은 거의 동일한 가치, 즉 거의 동일한 이점을 가지며 거의 동일한 방식으로 측정됩니다.

첫째, 배송 속도를 높일 수 있습니다. 이를 통해 어떻게 배송 속도를 높일 수 있나요? 코드 베이스에 새로운 변경 사항을 적용하면 즉시 이 코드로 작업을 시도할 수 있습니다. 우리는 목요일이 올 때까지 기다리지 않습니다. 목요일에 QA 환경에 릴리스하고 바로 여기에서 수행하기 때문입니다.

내 인생의 슬픈 이야기를 하나 들려 드리겠습니다. 아주 오래 전, 내가 아직 젊고 잘생겼던 때였습니다. 이제 나는 이미 젊고, 아름답고, 똑똑하고, 겸손합니다. 얼마 전 나는 프로젝트에 참여했습니다. 우리는 약 30명의 개발자로 구성된 대규모 팀을 보유하고 있었습니다. 그리고 우리는 약 10년 동안 개발한 대규모 엔터프라이즈 프로젝트를 진행했습니다. 그리고 우리는 다른 지점을 가졌습니다. 저장소에는 개발자가 이동하는 분기가 있었습니다. 그리고 프로덕션 중인 코드 버전을 표시하는 분기도 있었습니다.

프로덕션 브랜치는 개발자가 사용할 수 있는 브랜치보다 3개월 늦었습니다. 이것은 무엇을 의미 하는가? 이는 개발자의 잘못으로 인해, 그들이 허용했기 때문에, 그리고 QA의 잘못으로 인해, 그들이 그것을 살펴보았기 때문에 어딘가에 버그가 있으면 프로덕션으로 이동하는 즉시, 내가 프로덕션용 핫픽스 작업을 수행한 다음 3개월 전 코드 변경 사항을 롤백해야 합니다. 3개월 전에 겪었던 일을 기억하고 거기에서 고치도록 노력해야 합니다.

아직 이런 경험이 없다면 홈 프로젝트에서 시도해 볼 수 있습니다. 가장 중요한 것은 상업용으로 시도하지 않는 것입니다. 몇 줄의 코드를 작성하고 XNUMX개월 동안 잊어버린 다음 다시 돌아와서 해당 코드 줄이 무엇인지, 어떻게 수정하거나 최적화할 수 있는지 빠르게 설명하십시오. 그것은 매우 흥미로운 경험입니다.

지속적 통합 방식을 사용하는 경우 코드를 작성하자마자 바로 지금 여기에서 여러 자동화 도구를 사용하여 이를 확인할 수 있습니다. 이것이 전체 그림을 제공하지는 못하더라도 최소한 일부 위험은 제거할 것입니다. 그리고 잠재적인 버그가 있으면 지금 당장, 즉 문자 그대로 몇 분 안에 그 사실을 알게 될 것입니다. 3개월을 롤백할 필요는 없습니다. 2분만 롤백하면 됩니다. 좋은 커피 머신은 2분 안에 커피를 끓일 시간조차 없기 때문에 꽤 좋습니다.

이는 각 프로젝트에서 계속해서 반복될 수 있다는 가치가 있습니다. 당신이 설정한 것만이 아닙니다. 연습 자체를 반복할 수 있으며 프로젝트에 새로운 변경이 있을 때마다 CI 자체가 반복됩니다. 이를 통해 팀이 보다 효율적으로 작업하기 때문에 리소스를 최적화할 수 있습니다. 3개월 전에 작업한 코드에서 버그가 발생하는 상황은 더 이상 발생하지 않습니다. 앉아서 처음 두 시간 동안 무슨 일이 일어났는지 이해하고 뭔가 수정을 시작하기 전에 맥락의 본질에 들어가려고 노력할 때 더 이상 맥락 전환이 필요하지 않습니다.

이 관행의 성공 또는 실패를 어떻게 측정할 수 있습니까? 우리가 CI 프로젝트에서 구현한 내용을 상사에게 보고하면 그는 어쩌고 저쩌고 하는 말을 듣습니다. 우리는 그것을 구현했습니다. 하지만 왜, 그것이 우리에게 무엇을 가져왔는지, 어떻게 측정하는지, 얼마나 정확하거나 부정확하게 구현하고 있습니까?

첫 번째는 CI 덕분에 코드가 잠재적으로 더 안정적이기 때문에 점점 더 자주, 더 정확하게 배포할 수 있다는 것입니다. 마찬가지로, 오류를 찾는 시간이 단축되고, 이 오류를 수정하는 시간이 정확하게 단축됩니다. 바로 지금 여기 시스템에서 코드에 어떤 문제가 있는지에 대한 답변을 받기 때문입니다.

우리가 가지고 있는 또 다른 관행은 CI 관행과 함께 가장 자주 제공되는 자동화 테스트 관행입니다. 그들은 서로 협력합니다.

여기서 이해하는 것이 중요한 것은 무엇입니까? 우리의 테스트가 다르다는 것을 이해하는 것이 중요합니다. 그리고 각각의 자동화된 테스트는 자체 문제를 해결하는 것을 목표로 합니다. 예를 들어, 모듈을 별도로 테스트할 수 있는 단위 테스트가 있습니다. 진공 상태에서는 어떻게 작동하나요? 이것은 좋다.

또한 서로 다른 모듈이 서로 어떻게 통합되는지 이해할 수 있는 통합 테스트도 있습니다. 그것은 또한 좋다.

UI 작업이 고객이 설정한 특정 요구 사항을 얼마나 잘 충족하는지 확인할 수 있는 UI 자동화 테스트가 있을 수 있습니다.

실행하는 특정 테스트는 실행 빈도에 영향을 미칠 수 있습니다. 단위 테스트는 일반적으로 짧고 작게 작성됩니다. 그리고 정기적으로 출시될 수도 있습니다.

UI 자동화 테스트에 관해 이야기하고 있다면 프로젝트가 작다면 좋습니다. UI 자동화 테스트에는 적절한 시간이 걸릴 수 있습니다. 그러나 일반적으로 UI 자동화 테스트는 대규모 프로젝트에서 몇 시간이 소요됩니다. 그리고 몇 시간이면 좋습니다. 유일한 것은 모든 빌드에 대해 이를 실행할 필요가 없다는 것입니다. 밤에 실행하는 것이 합리적입니다. 그리고 테스터와 개발자 모두가 아침에 출근했을 때 밤에 UI 자동 테스트를 실행하여 이러한 결과를 얻었다는 일종의 보고를 받았습니다. 그리고 여기에서 귀하의 제품이 일부 요구 사항을 충족하는지 확인하는 서버의 한 시간 작업은 동일한 QA 엔지니어의 한 시간 작업보다 훨씬 저렴합니다. 음식을 위해 일하고 감사하는 주니어 QA 엔지니어라도 마찬가지입니다. 그럼에도 불구하고 기계를 한 시간 동안 작동하는 것이 더 저렴할 것입니다. 그렇기 때문에 투자하는 것이 합리적입니다.

제가 진행하고 있는 또 다른 프로젝트가 있습니다. 우리는 이 프로젝트에 대해 4주간의 스프린트를 가졌습니다. 이 프로젝트는 규모가 크고 금융 부문에 중요하며 실수가 있을 수 없습니다. 그리고 4주간의 스프린트 후에 개발 주기에 이어 테스트 프로세스가 이어졌고, 이는 또 XNUMX주가 걸렸습니다. 비극의 규모를 상상해보십시오. 우리는 XNUMX주 동안 코드를 작성한 다음 CodeFreeze로 코드를 작성하고 이를 새 버전의 애플리케이션으로 패키징한 다음 테스터에게 배포합니다. 테스터는 이를 XNUMX주 더 테스트합니다. 테스트하는 동안 우리는 두 가지 버전을 더 준비할 시간이 있습니다. 정말 안타까운 사례입니다.

그리고 우리는 생산성을 높이고 싶다면 자동화된 테스트 방식을 구현하는 것이 합리적이라고 말했습니다. 왜냐하면 이것이 바로 지금 여기에서 당신에게 해를 끼치기 때문입니다.

지속적인 배포를 연습하세요. 좋습니다. 빌드를 완료하셨습니다. 이것은 이미 좋습니다. 귀하의 코드가 컴파일되었습니다. 이제 이 빌드를 일부 환경에 배포하는 것이 좋을 것입니다. 개발자를 위한 환경을 가정해 보겠습니다.

왜 중요 함? 먼저 배포 프로세스 자체가 얼마나 성공적인지 확인할 수 있습니다. 저는 이와 같은 프로젝트를 만난 적이 있습니다. “새 버전의 애플리케이션을 배포하는 방법은 무엇입니까?”라고 물으면 사람들은 “우리는 그것을 조립하여 zip 아카이브에 압축합니다. 메일로 관리자에게 보내드립니다. 관리자는 이 아카이브를 다운로드하고 확장합니다. 그리고 사무실 전체가 서버가 새 버전을 선택하도록 기도하기 시작합니다.”

간단한 것부터 시작해 보겠습니다. 예를 들어, CSS를 아카이브에 넣는 것을 잊었거나 자바 스크립트 파일 이름에서 해시태그를 변경하는 것을 잊었습니다. 그리고 우리가 서버에 요청할 때 브라우저는 이미 이 자바 스크립트 파일이 있다고 생각하고 다운로드하지 않기로 결정합니다. 그리고 이전 버전이 있었는데 뭔가 빠졌습니다. 일반적으로 많은 문제가 있을 수 있습니다. 따라서 지속적인 배포를 수행하면 깨끗한 참조 이미지를 가져와 완전히 깨끗한 새 환경에 업로드하면 어떤 일이 발생하는지 최소한 테스트할 수 있습니다. 이것이 어디로 가는지 알 수 있습니다.

또한 서로 코드를 통합할 때, 즉 명령 사이에 명령이 UI에 어떻게 표시되는지 확인할 수도 있습니다.

바닐라 자바스크립트를 많이 사용하는 곳에서 발생하는 문제 중 하나는 두 명의 개발자가 성급하게 윈도우 객체에 같은 이름의 변수를 선언했다는 점이다. 그리고 운에 따라. 두 번째로 가져온 Java 스크립트 파일은 다른 파일의 변경 사항을 덮어씁니다. 그것은 또한 매우 흥미롭습니다. 당신이 들어옵니다. 한 사람에게는 한 가지가 효과가 있고 다른 것은 다른 사람에게는 효과가 없습니다. 그리고 이 모든 것이 프로덕션에서 나올 때 그것은 "훌륭합니다".

다음 방법은 자동 복원 방법, 즉 이전 버전의 애플리케이션으로 롤백하는 것입니다.

이것이 개발자에게 왜 중요한가요? 컴퓨터는 크고 프로그램은 작았던 멀고도 먼 90년대를 기억하는 사람들이 아직도 있습니다. 그리고 웹 개발을 할 수 있는 유일한 방법은 PHP를 통해서였습니다. PHP가 나쁜 언어는 아니지만, 그렇습니다.

하지만 문제는 달랐다. PHP 사이트의 새 버전을 배포할 때 어떻게 배포했습니까? 가장 자주 우리는 Far Manager 또는 다른 것을 열었습니다. 그리고 이 파일들을 FTP에 업로드했습니다. 그리고 갑자기 우리는 작고 작은 버그가 있다는 것을 깨달았습니다. 예를 들어 세미콜론을 넣는 것을 잊었거나 데이터베이스 비밀번호를 변경하는 것을 잊었고 로컬 호스트에 있는 데이터베이스 비밀번호가 있습니다. 그리고 우리는 신속하게 FTP에 연결하여 바로 그곳에서 파일을 편집하기로 결정했습니다. 이건 그냥 불이야! 90년대에 유행했던 것이 바로 이것이다.

하지만 달력을 보지 않았다면 90년대는 거의 30년 전의 일입니다. 이제 모든 것이 조금 다르게 일어나고 있습니다. 그리고 그들이 다음과 같이 말할 때 비극의 규모를 상상해 보십시오. “우리는 프로덕션에 배포했지만 거기에서 문제가 발생했습니다. 여기에 귀하의 FTP 로그인 및 비밀번호가 있습니다. 프로덕션에 연결하여 신속하게 수정하세요.” 당신이 척 노리스라면 이것이 효과가 있을 것이다. 그렇지 않다면 버그 하나를 수정하면 버그가 10개 더 생길 위험이 있습니다. 이것이 바로 이전 버전으로 롤백하는 방법을 통해 많은 것을 얻을 수 있는 이유입니다.

어떤 나쁜 일이 어딘가에서 자극을 받았다고 해도 그것은 나쁘지만 치명적이지는 않습니다. 사용 중인 이전 버전으로 롤백할 수 있습니다. 해당 용어로 인식하는 것이 더 쉽다면 백업이라고 부르세요. 이전 버전으로 롤백할 수 있으며 사용자는 계속해서 제품을 사용할 수 있으며 적절한 버퍼 시간을 갖게 됩니다. 서두르지 않고 침착하게 이 모든 것을 로컬에서 테스트하고 수정한 다음 새 버전을 업로드할 수 있습니다. 이렇게 하는 것이 정말 의미가 있습니다.

이제 이전의 두 가지 관행을 어떻게든 결합해 보겠습니다. 릴리스 관리라는 세 번째 항목이 제공됩니다.

고전적인 형태의 지속적인 배포에 관해 이야기할 때 저장소의 일부 브랜치에서 코드를 가져와서 컴파일하고 배포해야 한다고 말합니다. 같은 환경이면 좋아요. 여러 환경이 있는 경우 이는 동일한 커밋에서도 매번 코드를 가져와야 함을 의미합니다. 우리는 매번 그것을 꺼내어 매번 구축하고 새로운 환경에 배포할 것입니다. 첫째, 프로젝트를 구축하는 데 대규모 프로젝트가 있고 90년대에서 온 경우 몇 시간이 걸릴 수 있기 때문에 지금입니다.

게다가 아쉬운 점은 또 있다. 빌드할 때 동일한 머신에서라도 동일한 소스를 빌드하게 되지만 이 머신이 마지막 빌드와 동일한 상태에 있다는 보장은 여전히 ​​없습니다.

누군가가 와서 DotNet을 업데이트했거나 반대로 누군가가 무언가를 삭제하기로 결정했다고 가정해 보겠습니다. 그리고 XNUMX주 전 이 커밋에서 빌드를 구축하고 있었고 모든 것이 괜찮았지만 지금은 우리가 구축하려는 것과 동일한 기계, 동일한 커밋, 동일한 코드처럼 보이지만 작동하지 않는다는 인지적 부조화가 발생합니다. . 당신은 이 문제를 오랫동안 다루게 될 것이며 당신이 그것을 알아낼 것이라는 것은 사실이 아닙니다. 적어도 당신은 당신의 신경을 많이 망칠 것입니다.

따라서 릴리스 관리 실무에서는 아티팩트 저장소, 갤러리 또는 라이브러리라는 추가 추상화 도입을 제안합니다. 원하는 대로 부를 수 있습니다.

주요 아이디어는 다양한 환경에 배포할 준비가 된 브랜치에서 어떤 종류의 커밋이 발생하자마자 이 커밋에서 애플리케이션과 이 애플리케이션에 필요한 모든 것을 수집하고 압축하는 것입니다. zip 아카이브에 넣고 신뢰할 수 있는 저장소에 저장하세요. 그리고 이 저장소에서 언제든지 이 zip 아카이브를 얻을 수 있습니다.

그런 다음 이를 가져와 자동으로 개발 환경에 배포합니다. 우리는 그곳에서 경주를 하고 모든 것이 괜찮다면 무대에 배치됩니다. 모든 것이 정상이라면 동일한 아카이브, 동일한 바이너리를 정확히 한 번 컴파일하여 프로덕션에 배포합니다.

또한, 이와 같은 갤러리가 있으면 이전 버전으로의 롤백에 대해 이야기할 때 마지막 슬라이드에서 언급한 위험을 해결하는 데에도 도움이 됩니다. 실수로 잘못된 것을 배포한 경우 언제든지 이 갤러리에서 다른 이전 버전을 가져와 동일한 방식으로 이러한 환경에 배포를 취소할 수 있습니다. 이를 통해 문제가 발생하면 이전 버전으로 쉽게 롤백할 수 있습니다.

또 다른 훌륭한 연습이 있습니다. 여러분과 저는 애플리케이션을 이전 버전으로 롤백할 때 이전 버전의 인프라도 필요하다는 것을 모두 알고 있습니다.

가상 인프라에 대해 이야기할 때 많은 사람들은 이것이 관리자가 설정하는 것이라고 생각합니다. 예를 들어 애플리케이션의 새 버전을 테스트할 새 서버가 필요한 경우 관리자나 개발자에게 티켓을 작성해야 합니다. Devops는 이를 위해 3주가 소요됩니다. 그리고 3주 후에는 3개의 코어, XNUMXGB의 RAM, DotNet이 없는 Windows 서버를 갖춘 가상 머신을 설치했다고 알려줄 것입니다. 당신은 "하지만 나는 DotNet을 원했어요"라고 말합니다. 그들은: “알겠습니다. XNUMX주 후에 다시 오세요.”

인프라를 코드 방식으로 사용하면 가상 인프라를 또 다른 리소스로 취급할 수 있다는 아이디어입니다.

아마도 DotNet에서 애플리케이션을 개발하는 사람이라면 Entity Framework라는 라이브러리에 대해 들어봤을 것입니다. 그리고 Entity Framework가 Microsoft가 적극적으로 추진하고 있는 접근 방식 중 하나라는 말을 들어보셨을 것입니다. 데이터베이스 작업의 경우 이는 Code First라는 접근 방식입니다. 이는 데이터베이스가 어떻게 보이길 원하는지 코드로 설명하는 경우입니다. 그런 다음 애플리케이션을 배포합니다. 이는 데이터베이스에 연결하고, 어떤 테이블이 있고 어떤 테이블이 없는지 자체적으로 결정하고 필요한 모든 것을 생성합니다.

인프라에서도 동일한 작업을 수행할 수 있습니다. 프로젝트에 데이터베이스가 필요한지 또는 프로젝트에 Windows 서버가 필요한지 여부에는 차이가 없습니다. 그것은 단지 자원일 뿐입니다. 그리고 이 리소스의 생성을 자동화할 수 있고 이 리소스의 구성을 자동화할 수 있습니다. 따라서 새로운 개념, 새로운 접근 방식을 테스트하고 싶을 때마다 DevOps에 대한 티켓을 작성할 필요가 없으며 미리 만들어진 템플릿, 미리 만들어진 스크립트에서 격리된 인프라를 직접 배포하고 구현할 수 있습니다. 거기에 모든 실험이 있습니다. 이를 삭제하고 일부 결과를 얻은 다음 이에 대해 추가로 보고할 수 있습니다.

역시 존재하고 중요하지만 소수의 사람들이 사용하는 다음 방법은 애플리케이션 성능 모니터링입니다.

저는 애플리케이션 성능 모니터링에 대해 한 가지만 말하고 싶었습니다. 이 관행에서 가장 중요한 것은 무엇입니까? 이것이 바로 애플리케이션 성능 모니터링이 아파트 수리와 거의 같습니다. 이것은 최종 상태가 아니라 하나의 과정입니다. 정기적으로 해야 합니다.

좋은 의미에서는 거의 모든 빌드에서 애플리케이션 성능 모니터링을 수행하는 것이 좋지만, 아시다시피 이것이 항상 가능한 것은 아닙니다. 그러나 최소한 각 릴리스마다 수행해야 합니다.

왜 중요 함? 갑자기 성능 저하가 발생한다면 그 이유를 명확하게 이해해야 하기 때문입니다. 예를 들어 팀이 XNUMX주간의 스프린트를 수행하는 경우 적어도 XNUMX주에 한 번씩 프로세서, RAM, 디스크 등이 확실히 고정된 별도의 서버에 애플리케이션을 배포해야 합니다. 그리고 동일한 성능 테스트를 실행해야 합니다. . 당신은 결과를 얻습니다. 이전 스프린트와 어떻게 달라졌는지 확인해 보세요.

그리고 하락폭이 어디선가 급격히 하락했다는 사실을 알게 된다면 그것은 단지 지난 XNUMX주 동안 일어난 변화 때문이라는 뜻일 것입니다. 이를 통해 문제를 훨씬 빠르게 식별하고 해결할 수 있습니다. 그리고 다시 말하지만, 이는 얼마나 성공적으로 수행했는지 측정할 수 있는 측정항목과 거의 동일합니다.

다음 실습은 구성 관리 실습입니다. 이것을 진지하게 받아들이는 사람은 거의 없습니다. 하지만 저를 믿으십시오. 이것은 실제로 매우 심각한 일입니다.

최근 재미있는 이야기가 있었습니다. 그 사람들이 나에게 와서 "우리 애플리케이션에 대한 보안 감사를 수행하도록 도와주세요."라고 말했습니다. 우리는 오랫동안 함께 코드를 보았고 그들은 나에게 애플리케이션에 대해 이야기하고 다이어그램을 그렸습니다. 그리고 플러스 마이너스 모든 것이 논리적이고 이해 가능하며 안전했지만 한 가지가있었습니다! 그들은 IP 데이터베이스가 있는 프로덕션 파일, 이러한 데이터베이스에 연결하기 위한 로그인 및 비밀번호 등을 포함하여 소스 제어에 구성 파일을 가지고 있었습니다.

그리고 저는 이렇게 말합니다. "여러분, 방화벽으로 프로덕션 환경을 닫았지만 소스 제어에 바로 프로덕션 데이터베이스에 대한 로그인과 비밀번호가 있고 모든 개발자가 이를 읽을 수 있다는 사실은 이미 엄청난 보안 위험입니다. . 그리고 코드 관점에서 애플리케이션이 아무리 안전하더라도 소스 제어에 그대로 두면 어느 곳에서도 감사를 통과할 수 없습니다.” 그것이 내가 말하는 것입니다.

구성 관리. 우리는 다른 환경에서 다른 구성을 가질 수 있습니다. 예를 들어, QA, 데모, 프로덕션 환경 등을 위한 데이터베이스의 로그인 및 비밀번호가 다를 수 있습니다.

이 구성은 자동화될 수도 있습니다. 이는 항상 애플리케이션 자체와 분리되어야 합니다. 왜? 애플리케이션을 한 번 구축한 다음 애플리케이션은 이러한 IP 또는 이러한 IP를 통해 SQL 서버에 연결하는지 여부에 상관하지 않으므로 동일하게 작동해야 합니다. 그러므로 갑자기 여러분 중 누군가가 여전히 코드에 연결 문자열을 하드코딩하고 있다면, 여러분이 나와 같은 프로젝트에 참여하고 있는 것을 발견하면 제가 여러분을 찾아서 처벌할 것이라는 점을 기억하십시오. 이는 항상 web.config와 같은 별도의 구성에 배치됩니다.

그리고 이 구성은 이미 별도로 관리되고 있습니다. 즉, 개발자와 관리자가 같은 방에 와서 앉을 수 있는 바로 그 순간입니다. 그리고 개발자는 이렇게 말할 수 있습니다. “보세요, 여기 내 애플리케이션의 바이너리가 있습니다. 그들은 일합니다. 애플리케이션이 작동하려면 데이터베이스가 필요합니다. 여기 바이너리 옆에 파일이 있습니다. 이 파일에서 이 필드는 로그인을 담당하고, 비밀번호, IP를 담당합니다. 어디에든 배포하세요." 관리자에게는 간단하고 명확합니다. 그는 이 구성을 관리함으로써 실제로 어디에나 배포할 수 있습니다.

그리고 제가 이야기하고 싶은 마지막 관행은 클라우드와 매우 관련이 깊은 관행입니다. 그리고 클라우드에서 작업하면 최대의 효과를 얻을 수 있습니다. 이는 환경을 자동으로 제거하는 것입니다.

이번 컨퍼런스에는 제가 함께 일하는 팀에서 여러 사람이 참석하고 있다는 것을 알고 있습니다. 그리고 제가 함께 일하는 모든 팀에서는 이 방법을 사용합니다.

왜? 물론, 각 개발자가 연중무휴 24시간 작동하는 가상 머신을 가지고 있다면 좋을 것입니다. 그러나 아마도 이것은 당신에게 뉴스일 수도 있고, 아마도 주의를 기울이지 않았을 수도 있지만 개발자 자신은 연중무휴로 일하지 않을 것입니다. 개발자는 보통 하루 7시간 일합니다. 일찍 출근하더라도 점심을 든든히 먹고 헬스장에 간다. 개발자가 실제로 이러한 리소스를 사용하는 시간을 하루 24시간으로 놔두세요. 우리 법률에 따르면 일주일 중 7일 중 8일이 근무일로 간주됩니다.

따라서 평일에는 이 기계가 24시간이 아니라 12시간만 작동해야 하며, 주말에는 이 기계가 전혀 작동하지 않아야 합니다. 모든 것이 매우 단순해 보이지만 여기서 말하는 것이 중요한 것은 무엇입니까? 이 기본 일정에 따라 이 간단한 방법을 구현하면 이러한 환경을 유지하는 데 드는 비용을 70%까지 줄일 수 있습니다. 즉, 개발, QA, 데모, 환경의 가격을 3으로 나눈 것입니다.

문제는 남은 돈으로 무엇을 하느냐는 것이다. 예를 들어 개발자는 아직 ReSharper를 구매하지 않았다면 구매해야 합니다. 아니면 칵테일 파티를 해보세요. 이전에 개발팀과 QA팀이 모두 참여하는 하나의 환경이 있었다면 이제 격리된 3개의 서로 다른 환경을 만들 수 있으며 사람들은 서로 간섭하지 않습니다.

지속적인 성과 측정이 포함된 슬라이드와 관련하여 프로젝트의 데이터베이스에 1개의 레코드가 있고 두 달 후 000만 개가 있는 경우 성과를 어떻게 비교할 수 있습니까? 성과를 측정하는 이유와 요점을 이해하는 방법은 무엇입니까?

항상 동일한 리소스에 대한 성능을 측정해야 하기 때문에 이는 좋은 질문입니다. 즉, 새 코드를 출시하고 새 코드의 성능을 측정합니다. 예를 들어 다양한 성능 시나리오를 테스트해야 합니다. 사용자가 1명이고 데이터베이스 크기가 000GB인 가벼운 로드에서 애플리케이션이 어떻게 작동하는지 테스트한다고 가정해 보겠습니다. 당신은 그것을 측정하고 숫자를 얻었습니다. 다음으로 우리는 또 다른 시나리오를 취합니다. 예를 들어 사용자가 5명이고 데이터베이스 크기가 5테라바이트입니다. 우리는 결과를 받고 기억했습니다.

여기서 중요한 것은 무엇입니까? 여기서 중요한 점은 시나리오, 데이터 양, 동시 사용자 수 등에 따라 특정 제한이 발생할 수 있다는 것입니다. 예를 들어 네트워크 카드 한도, 하드 드라이브 한도, 프로세서 기능 한도 등입니다. 이것이 당신이 이해하는 것이 중요한 것입니다. 다양한 시나리오에서는 특정 제한에 직면하게 됩니다. 그리고 숫자를 칠 때 숫자를 이해해야 합니다.

특수 테스트 환경에서의 성능 측정에 대해 이야기하고 있습니까? 즉, 이것은 생산이 아닌가?

예, 이것은 프로덕션이 아니며 테스트 환경이므로 이전 측정값과 비교할 수 있도록 항상 동일합니다.

알았어, 고마워!

질문이 없으면 끝낼 수 있을 것 같아요. 감사합니다!

출처 : habr.com