DevOps는 소프트웨어 회사에서 받을 수 있는 가장 높은 보수를 받는 역할 중 하나입니다. DevOps로 일하지 않더라도 어떻게 작동하는지 알면 더 생산적인 개발자가 될 것입니다.

freeCodeCamp.org YouTube 채널에 DevOps Engineering 과정을 게시했습니다. 초보자를 위한 이 포괄적인 과정에서 세 가지 기술 자습서를 통해 DevOps에 대해 모두 알아보십시오.

Colin Chartier가 이 과정을 만들었습니다. 그는 LayerCI의 공동 창립자이자 CEO입니다.

DevOps가 무엇인지, 지속적 통합, 지속적 배포 전략 및 애플리케이션 성능 관리를 배우게 됩니다. 많은 DevOps 관행은 프로그래밍 및 웹 개발에 일반적으로 사용되며 주요 용어 및 기술을 이해하는 것이 중요합니다.

이 과정은 종종 MERN (MongoDB, Express JS, React JS, Node JS) 기술 스택을 참조합니다. 이러한 모범 사례를 기반으로 한 기술 권장 사항과 함께 일련의 대화를 받게 됩니다. 이 강연에는 몇 가지 프로그래밍 예제가 포함되어 있습니다. 코딩과 웹의 절대적인 기초를 아는 한 따라가는 데 아무런 문제가 없습니다.

이 과정의 섹션은 다음과 같습니다.

단원 1-코드 검토 자동화 

• 레슨 1 -  DevOps 란?
• 레슨 2 - TDD (Test Driven Development) 란 무엇입니까?
• 레슨 3 - 지속적 통합 (CI)이란 무엇입니까? w / CI 설정 튜토리얼
• 레슨 4 - 코드 커버리지 란 무엇입니까?
• 레슨 5-Linting 모범 사례
• 레슨 6-자습서 설정이 포함 된 임시 환경

단원 2-배포 전략 

• 레슨 7-가상 머신 (VM) 대 컨테이너
• 레슨 8-롤링 배포
• 레슨 9-지속적 배포 설정이 포함 된 블루 / 그린 배포 자습서
• 레슨 10-자동 확장이란?
• 레슨 11-서비스 검색이란 무엇입니까?

단원 3-애플리케이션 성능 관리 (APM) 

• 레슨 12-로그 집계 란 무엇입니까?
• 레슨 13-필수 생산 지표

아래 또는 freeCodeCamp.org YouTube 채널 (2 시간 시청)에서 전체 과정을 시청하세요.

이 초급 DevOps 과정은 DevOps 엔지니어링 역할을 향한 첫 번째 단계입니다. LayerCI의 CEO이자 공동 설립자가 가르칩니다.

이 과정의 목표는 일반 개발자와 일반 엔지니어링 실무자가 DevOps 엔지니어링 역할을 수행 할 수 있도록 기본적인 DevOps 개념을 배우는 것입니다. 또한 소개에서 DevOps에 대해 광범위하게 이야기 할 것입니다. 그러나 그 이상으로 주로 사물의 엔지니어링 측면에 대해 이야기 할 것입니다.

DevOps는 사용자 피드백을 지속적으로 통합하여 엔지니어링 팀이 제품을 더 잘 구축 할 수 있도록 지원하는 방법론입니다.

Google DevOps를 검색하고 사진을 찾으면 이와 같은 사진을 자주 볼 수 있습니다. DevOps가 개발 된 소프트웨어에 대한 기존의 사고 방식과 어떻게 다른지 이해하는 데 도움이 됩니다. 예전에는 공장에서 개발되는 것처럼 소프트웨어가 개발되었습니다. 따라서 모든 입력은 프로그래밍이고 출력은 CD에 넣을 수 있는 제품을 사용자에게 판매하는 것입니다.

그러나 인터넷의 출현과 지속적으로 업데이트 가능한 소프트웨어가 있기 때문에 새로운 버전의 제품을 만드는 대신 제품을 시작하고 사용자 피드백을 받아 현재 제품에 통합하는 것이 정말 쉬워졌습니다. 따라서 Facebook과 같은 웹 사이트는 새로운 버전의 Facebook을 구매하도록 요구하는 대신 지속적으로 업그레이드합니다. 아시다시피 일부 도시와 같은 오래된 게임은 SimCity의 새 버전을 구입해야 합니다. 그리고 그 아이디어는 DevOps에 의해 실제로 공식화 되었으며 섹션은 계획 중이며 구축하려는 기능 세트를 사용합니다. 팀과 협력하여 이러한 기능에 대한 몇 가지 사양을 다음과 같이 만들 수 있습니다.

당신은 그들을 코딩합니다. 따라서 팀의 개발자는 이러한 기능을 빌드하여 출시 할 수 있습니다. 그리고 물론 그들은 만들어졌습니다. 따라서 웹 사이트의 경우 소스 코드를 가져 와서 사용자의 브라우저에서 실행할 수 있는 JavaScript로 번들링 할 수 있습니다. 비디오 게임의 경우 Linux에서 실행되는 다양한 버전과 Windows에서 실행되는 버전 및 브라우저에서 실행되는 버전에 대한 릴리스를 만들 수 있습니다. 그래서 여러분은 이렇게 만들어진 인공물을 가져 와서 테스트합니다. 따라서 테스트는 자동 및 수동입니다. 자동 테스트는 일반적으로 지속적 통합으로 알려져 있습니다. 수동 테스트는 일반적으로 품질 보증, QA로 알려져 있습니다.

그런 다음 테스트를 마치고 이해 관계자가 모두 피드백을 제공 한 후 공개됩니다. 지속적인 배포 전략, 릴리스 및 배포는 모두 변경이 양호한 것으로 확인 된 후 자동으로 발생합니다. 여기서 수행 할 수 있는 많은 자동화가 있습니다. 더 큰 팀에서. 아시다시피 Netflix의 Spinnaker와 같은 인기 있는 도구가 있으며 나중에 이야기 할 것입니다. 하지만 핵심 아이디어는 소프트웨어를 가져 와서 문제가 있는지 사용자가 알지 못하는 방식으로 사용자에게 보내려는 것입니다. 따라서 실험적인 UI 변경 사항이 있는 경우 이를 광범위하게 표시하기 전에 일부 사용자에게 표시하고 피드백을 받을 수 있습니다. 다시 말하지만, 수십억 명의 사용자가 있는 Facebook과 같은 회사는 사용자의 1 %가 불만을 제기하더라도 수억 개의 이메일을 받게 되며 릴리스가 구축되고 배포됩니다. 따라서 배포는 웹 사이트를 위해 사용자에게 공개된다는 것을 의미하며 인터넷에서 공개적으로 액세스 할 수 있음을 의미합니다. CD ROM의 경우 CD에 번들로 묶어 모바일 릴리스에 배포하고 아티팩트를 빌드하고 App Store에 제출합니다. 그런 다음 App Store는 이를 검토 한 다음 사용자가 다운로드 할 수 있는 새 업데이트를 게시합니다.

그런 다음 작동합니다. 운영은 주로 확장과 같은 것입니다. 부하에 충분한 리소스가 있는지 확인하고 필요에 따라 서버를 추가합니다. 본질적으로 모니터링에서 아키텍처 문제를 처리하는 구성. 따라서 사용자가 소프트웨어를 사용하고 특히 항목을 제출하고 작업을 시작하고 포럼에 게시물을 작성할 때 해당 게시물이 모두 정상인지 확인해야 합니다.

그리고 마지막으로 이 모든 피드백을 받아 계획 단계로 되돌립니다. 따라서 계획 단계에서는 모든 사용자 피드백이 운영 및 배포, 팀에서 제품 배포 및 확장에 대해 배운 모든 것을 가져옵니다. 그런 다음 이를 사용하여 새로운 기능을 구축하고 버그를 해결하며 새 버전의 백엔드와 새 버전의 아키텍처를 만듭니다. 그리고 그 사이클에서 계속됩니다. 그리고 이것이 사람들이 말하는 것, 우리 회사가 DevOps를 사용하거나, 우리 회사가 기술을 발전 시키거나, 우리 회사가 디지털로 변모했다고 말할 때 의미하는 것입니다. 이는 일련의 요구 사항을 취하고 하나의 아티팩트를 구축 한 다음 배송되는 대신 피드백을 받는 지속적인 주기임을 의미합니다. 일반적으로 이 2 주 스크럼주기에서 사용자가 실제로 사용하고 싶은 소프트웨어를 생산하는 것은 DevOps 엔지니어링을 생산할 때 일부가 말했듯이 DevOps의 또 다른 공통 부분입니다. 따라서 기술 리더와 CEO가 관심을 가질만한 방법론 외에도 DevOps 엔지니어링의 하위 분야가 있으며, 이것이 일반적으로 엔지니어가 의미하는 바입니다.

그들이 DevOps를 말할 때 알다시피, 그것이 일반적으로 그들이 DevOps를 말할 때 채용 공고가 의미하는 바입니다. 따라서 채용 공고에서 DevOps 엔지니어를 요구하는 경우 코드를 계획하고 배포 할 수 있는 사람을 요구하는 것이 아닙니다. 그들은 주로 테스트를 구축하고, 출시하고, 배포하고, 모니터링 할 수 있는 사람을 요구합니다.

따라서 DevOps 엔지니어링, 풀 리퀘스트 자동화, 배포, 자동화 및 애플리케이션 성능 관리의 세 가지 기둥입니다. 그리고 우리는 이것들에 대해 자세히 알아볼 것입니다. 그러나 아이디어는 풀 리퀘스트 자동화가 개발자가 작업을 더 빠르게 구축하고 제안 된 변경 사항이 좋은지 더 빠른지 이해하는 데 도움이 됩니다. 배포 자동화는 사용자가 불평하지 않는 방식으로 코드를 배포하는 데 도움이 됩니다. 다시 말하지만, Facebook은 많은 배포 자동화 기능을 가지고 있습니다. 왜냐하면 그들이 코드를 그냥 무효로 버리면 개발자가 변경할 때마다 수억 건의 불만이 있을 것이기 때문입니다. 그리고 애플리케이션 성능 관리는 모든 것이 정상인지 확인하는 자동화입니다. 따라서 자동으로 다운 타임을 감지하고, 누군가를 깨우고, 알고 있다면 사이트가 밤새 다운되고 문제가 있으면 자동으로 롤백합니다. 그리고 우리는 앞으로의 회담에서 이 모든 것들에 대해 자세히 알아볼 것입니다.

제가 언급 한 첫 번째 기둥은 풀 리퀘스트 자동화가 주로 개발자 피드백주기와 관련이 있습니다. 따라서 개발자들은 풀 리퀘스트 (pull request)라고하는 이러한 원자 적 변경 세트를 제안함으로써 서로 작업을 공유합니다. 그리고 원자 적으로 말하면, 그것들은 그 자체로 완전한 기능을 갖추고 있으며, 다른 것들이 실행될 필요가 없습니다. 첫째, 개발자가 풀 리퀘스트를 제안하면 그 변경이 좋다고 기대해야 합니다. 그리고 그들이 말할 수 있는 한, 변경은 몇 가지 비즈니스 요구 사항을 충족합니다. 그리고 그들이 해야 할 일은 몇 개의 문을 통과하는 것입니다. 따라서 조직과 풀 리퀘스트 자동화의 목표는 개발자가 변경 사항이 좋은지 여부를 매우 빠르게 알 수 있도록하는 것입니다. 예를 들어 웹 사이트에서 작업 중이고 개발자가 오타를 추가하는 변경을 제안하면 자동으로 쉽게 감지 할 수 있습니다. 

그리고 오타가 포함 된 경우 변경 사항이 적용되지 않는다는 오타 게이트를 설정하면 개발자가 변경 사항에 대한 자동 피드백을 받을 수 있는 쉬운 방법이 될 것입니다. 사람들은 풀 리퀘스트라고 말합니다. 2021 년부터는 보통 Git을 의미합니다. 따라서 Git은 원래 Linux에서 대중화 된 기술이며 개발자가 이러한 종류의 변경을 수행하고 서로 공유하는 데 도움이 됩니다. 풀 리퀘스트는 일반적으로 적어도 한 명의 다른 프로그래머와 코드 리뷰라는 무언가에 의해 검토됩니다. 여기서 다른 프로그래머는 코드 스타일에 대해 알려줄 것입니다. 아키텍처 문제, 확장 문제, 쉽게 할 수 없는 주관적인 사항이 있는지 여부를 제안하는 프로그래머에게 알려줍니다. 자동화됩니다. 그러나 이러한 검토 프로세스는 DevOps 기술 스택에 의해 크게 촉진 될 수도 있습니다. 그리고 DevOps 자동화는 임시 환경 및 Linting과 같은 작업에 도움이 될 수 있습니다. 그리고 코드 검토가 완료된 후 우리가 들어갈 다른 모든 자동화에서.

일반적으로 제안 되는 기능을 담당하는 엔지니어링 관리자 또는 제품 관리자가 피드백을 받습니다. 따라서 웹 사이트에서 새 버튼을 생성하는 경우 버튼을 디자인 한 디자이너와 버튼을 요청한 제품 관리자가 생성되기를 원합니다. 둘 다 피드백을 제공합니다. 버튼이 제대로 배치되지 않은 경우, 모바일이 아닌 경우 반응 형이 아닌 경우 다른 병합 요청이 필요한 모든 문제이기 때문입니다. 따라서 원래 병합 요청이 처음 제안 되었을 때 모든 요구 사항을 충족하면 좋을 것입니다. 그리고 일반적으로 기술이 아닌 사람들은 필요에 따라 풀 요청에 대한 피드백을 제공합니다.

따라서 DevOps 엔지니어를 위해 자동화 할 수 있는 것은

다음과 같은 것을 자동화 할 수 있습니다.

자동화 된 테스트 실행, 변경에 따른 임시 환경, 자동화 된 보안 검색, 검토자를 통한 알림, 적시에 적절한 사람이 검토하도록 합니다. 그리고 이 모든 자동화의 최종 목표는 개발자가 변경을 제안하고 변경을 제안한 당일 병합 할 수 있어야 한다는 것입니다. 이는 중요한 버그를 특별한 프로세스 없이도 매우 빠르게 수정하고 병합 및 배포 할 수 있다는 것을 의미하기 때문에 조직적으로 큰 이점입니다. 또한 개발자가 관료주의에 얽매이지 않고 모든 게이트를 통과하면 변경 사항을 제안 할 수 있으며 변경 사항이 배포되며 발견해야 할 추가 특수 게이트가 없습니다. 예를 들어 적절한 게이트와 자동화가 설정되어 있다면 개발자는 회사의 모든 사람에게 물어볼 필요 없이 웹 페이지를 변경할 수 있어야 합니다. 이 웹 페이지가 특정 워크 플로에서 사용되는지 여부입니다. 테스트를 통과하고 QA 검토를 통과 한 덕분에 새로운 변경 사항이 좋다고 가정합니다. 문제가 발생하면 자동화에 새로운 게이트를 추가하여 향후 문제가 발생하지 않도록 할 수 있습니다. 두 번째 기둥은 배포 자동화입니다. 그리고 2000 년대의 유명한 포스트 인 Stack Overflow의 창립자 인 Can you make a build in one step을 개발 조직의 두 번째로 중요한 질문으로 꼽았습니다. 그 이후로 상황은 실제로 변하지 않았습니다.

구축 프로세스의 효율성이 배포 자동화의 유일한 목표는 아닙니다. 그러나 다른 목표에는 배포 전략이 포함되며, 다운 타임없이 애플리케이션의 새 버전을 시작하는 한 번에 한 사용자에게 기능을 표시하려는 Canary 배포에 대해 이야기했습니다. 업그레이드하기 전에 웹 사이트를 종료 한 다음 새 버전을 켜야 하는 경우 업그레이드 중간에 웹 사이트를 방문하는 방문자가 다운 타임을 알 수 있습니다. 따라서 이를 방지 할 수 있는 현명한 배포 전략이 있습니다. 마지막으로 문제가 발생할 경우 버전을 롤백합니다.

행성을 너무 복잡하게 만드는 것은 쉽습니다. 많은 회사가 릴리스를 빌드하고 배포하기 위한 복잡한 내부 플랫폼을 가지고 있습니다. 일반적으로 성공 및 배포 자동화는 비즈니스 목표를 달성하고 구성하는 데 적합한 배포 도구를 찾는 것입니다. 그리고 이상적인 세상에는 배포를 위한 사용자 지정 코드가 거의 또는 전혀 없어야 합니다. 따라서 Spinnaker 및 하네스와 같은 기성품 솔루션은 이러한 종류의 작업을 시작하기에 좋은 곳입니다.

마지막으로, 애플리케이션 성능 관리, 심지어 최고의 코드라도 운영 오류로 인해 방해를 받을 수 있습니다. 사용자가 Stack Overflow의 게시물 끝에 여러 개의 공백을 넣는 유명한 경우가 있습니다. 그리고 그들은 매우 유명한 개발자 웹 사이트 인 Stack Overflow를 다운 시켰습니다. Stack Overflow는 많은 공백을 잘 처리 할 수 있는 방식으로 코드를 배포하지 않았기 때문입니다. 따라서 게시물 끝에 공백 문자가 많고, 최고의 코드를 사용하고 메시지 보드와 같은 가장 단순한 것에서도 오류가 발생하기 쉽고 사용자 만 발견 할 수 있습니다. 따라서 애플리케이션 성능 관리는 요청을 처리하는 데 걸리는 시간, 사용 중인 서버 수, 모든 주요 상태 메트릭이 처리되는 것과 같은 메트릭을 보장합니다. 랜딩 페이지에 대한 모든 요청이 갑자기 오랜 시간이 걸리는 경우와 같은 문제가 발생하면 엔지니어가 자신의 웹 사이트가 다운되었음을 트위터에서 발견하는 대신 적절한 사람들에게 자동으로 알림을 받을 수 있습니다.

벌채 반출. 따라서 프로그램이 실행되면 로그가 생성됩니다. 그리고 로그에는 일반적으로 사물의 상태에 대한 정보가 있습니다. 사용자가 해당 사용자에 대한 정보로 웹 사이트를 방문한 것과 같이 로그를 다시 매핑 할 수 있으면 유용합니다. 그렇다면 그들의 IP 주소는 무엇입니까? 사용자 이름, 액세스 한 리소스, 액세스를 수행하는 데 사용 된 리소스 따라서 데이터베이스에서 무언가를로드해야하고 데이터베이스가 느렸다면 요청이 느리게 처리 되었기 때문에 사용자의 경험이 느렸다 고 말할 수 있으면 유용합니다. 그러나 요청은 데이터베이스에서 느리게 이행 되었기 때문에 느리게 이행되었습니다. 따라서 이러한 요청을 구성 요소까지 매핑 하는 것은 매우 유용합니다.

모니터링. 다시 말하지만, 메트릭스를 언급하고 사람들에게 자동으로 경고했지만 로그와 메트릭스, 남은 메모리 양이 얼마나 느린 지, 무엇을 할지 결정했습니다. 따라서 많은 부하가 있는 경우 메트릭을 기반으로 서버 수를 자동으로 확장하도록 결정할 수 있으므로 사용 중인 웹 서버를 더 추가하십시오. 로그를 기반으로 오류가있는 경우 엔지니어가 조사 할 수 있도록 티켓을 자동으로 제출할 수 있습니다. 그리고 가동 중지 시간이 있는 경우 누군가를 호출 중인 사람에게 전화하여 그들이 깨어나 가동 중지 시간을 처리하도록 할 수 있습니다. 그리고 그들은 모든 것을 떨어 뜨릴 수 있고, 말하자면 호출기를 가질 수 있습니다. 그리고 그것은 경고입니다. 따라서 경고는 오류가 감지되거나 메트릭을 기반으로 일부 트리거가 발생했거나 일부 요청 수 또는 느린 일이 비정상적입니다. 사용자가 성능 저하를 감지하거나 누군가에게 알려야 하거나 조치를 취해야 합니다. , 새로운 제품인 DevOps에 뛰어 들어서 한 번에 엔지니어링 해서는 안됩니다. 그래서 저는 넷플릭스와 페이스 북과 같은 대규모 조직의 최종 목표에 대해 이야기했습니다. 상황에 따라 자동화를 추가하는 개발자. 웹 사이트를 구축하는 사용자가 없는 새로운 스타트 업입니다.

기둥 2와 3은 본질적으로 쓸모없는 중단입니다. 다운 타임 같은 것은 누구도 알아 차리지 못할 것입니다. 반드시 중요하지는 않습니다. 자동화 된 테스트를 실행할 필요도 없고, 낮은 5와 같은 누군가를 위한 유용한 스택, 또는 다른 개발자와 협업 할 준비 환경을 얻을 수 있는 제품을 판매하거나 판매 할 필요가 없습니다. 그러나 그것은 현명한 테스트에 관심이 있는 한 모든 제안 된 변경에 대한 환경에 도달합니다. 또한 10 명의 기업 사용자를 위한 앱을 개발하는 팀이 좋은지 여부에 관계없이 수동 QA 설정에서 직접 작업 할 수 있습니다. 따라서 기업 사용자는 다운 타임에 훨씬 더 민감합니다. 따라서 테스트 적용 범위 및 업무 시간 알림이 우선되어야 합니다. 로깅 및 로그 집계 오류 수집에는 자동 테스트 실행을 위한 Century 및 Code Cove와 같은 인기 있는 도구가 있으며, 모바일 테스트 및 경고 용으로 알려진 비트 상승 및 원 CI 증발과 같은 도구가 있습니다. 추적을 유지하는 Pedro duty라는 유명한 도구가 있습니다. 다운 타임이 있는 경우 알림을 받아야 하는 사람 따라서 업무 시간 동안에는 하루 동안 회의에 참석하지 않아야 하는 사람을 지정할 수 있습니다. 다운 타임이 발생하면 모든 것을 중단하고 문제를 해결합니다.

그리고 Reddit과 같은 소셜 미디어 앱은 웹 사이트에서 오류를 포착하기 위해 세기에 걸쳐 많은 것의 조합을 사용하고 있습니다. Elasticsearch LogStash, Kibana는 로그를 수집하고 확인하는 인기 있는 방법입니다. pingdom은 특정 페이지가 응답하는 데 너무 오래 걸리는지 확인합니다. launchdarkly를 사용하면 기능 플래그를 추가 할 수 있습니다. 따라서 일부 사용자 그룹에 대해 기능이 활성화되어 있는지 여부를 말할 수 있습니다. 새 랜딩 페이지가 북미 또는 유럽의 사용자에게 표시되면 배포 프로세스를 자동화 할 수 있습니다. 따라서 서버 세트와 서버에서 실행해야 하는 일련의 항목이 주어지면 terraform은 올바른 항목이 올바른 위치에서 실행되도록 하는 계획을 자동으로 생성하는 데 도움이 됩니다.

그리고 이 모든 것의 결론은 DevOps 엔지니어링이 개발자 팀에게 필수적이라는 것입니다. 세 가지 기둥을 인식하면 고객은 혼란스럽고 실망스러운 경험을 할 수 있습니다. 일이 줄어들고 일이 제대로 확장되지 않고 일이 느려질 것입니다. 따라서 엔지니어링 조직을 확장하거나 DevOps 엔지니어로 고용되는 경우 세 가지 기둥을 염두에 두는 것이 정말 중요합니다. 신제품은 그다지 자동화 할 필요가 없습니다. 그러나 제품이 성숙하고 더 많은 사용자를 확보함에 따라 DevOps 엔지니어링을 자동화하고 더 많은 리소스를 여기에 할당하는 것이 점점 더 중요 해지고 있습니다.

코드 리뷰 자동화에 아주 좋은 아침입니다. 지속적인 통합 및 기타 코드 검토 자동화 주제에 대해 이야기 할 때 매우 중요한 기본 정보가 될 테스트에 대해 이야기 해 보겠습니다. 따라서 테스트 주도 개발은 코드가 작성되기 전에 테스트가 작성되는 코딩 방법론입니다. 그리고, 우리는 커피 메이커의 관점에서 테스트와 테스트 주도 개발을 설명 할 것입니다. 계속해서 멋진 커피 메이커 사진을 즐기세요.

테스트 주도 개발은 오랜 시간 동안 진행되었습니다. 2000 년대 초에 대중화되었습니다. 아이디어는 간단하지만 실제로 이해하기 위해서는 어떻게 되었는지에 대한 지식이 필요합니다.

따라서 역사적으로 품질 보증, QA 및 단위 테스트와 같은 소프트웨어 개발의 일반적인 단어는 실제 제품을 만드는 공장에 뿌리를 두고 있습니다. 공장 건물 커피 메이커를 운영하고 있다면 다양한 완성도에서 작동하는지 테스트 할 것입니다.

따라서 단위 테스트는 개별 구성 요소가 자체적으로 작동하는지 확인합니다. 히터가 작동합니까? 탱크에 물이 담겨 있습니까? 통합 테스트? 몇 가지 구성 요소가 함께 작동하는지 확인 하시겠습니까? 히터가 탱크의 물을 데우나요?

시스템 종단 간 테스트? 모든 것이 함께 작동하는지 확인 하시겠습니까? 커피 메이커가 커피를 추출합니까?

출시 후 수락 테스트를 고객에게 보냈습니까? 결과에 만족합니까? 버튼 레이아웃과 혼동되거나 보증 기간 내에 커피 메이커가 중단됩니까?

이러한 모든 테스트에는 소프트웨어 비유가 있으므로 문제를 진단하기 위해 어떤 구성 요소가 손상되었는지 아는 것이 유용합니다. 그러나 전체 시스템이 올바르게 작동하고 있음을 아는 것도 유용합니다. 모든 개별 구성 요소가 자체적으로 작동하고 커피 메이커가 히터로 물을 데우지 않더라도 커피를 만들 때 문제가 될 것입니다.

그것이 실제로 테스트를 위한 아이디어입니다. 하지만 지난 10 ~ 20 년 동안 인기를 끌었던 테스트를 기반으로 구축 된 방법론 인 테스트 주도 개발에 대해 알아 보겠습니다. 테스트 기반 개발을 사용하지 않는 대부분의 개발자는 유사한 워크 플로를 가지고 있으며 작업 할 항목을 선택합니다. DevOps에 대한 우리의 아이디어를 기반으로, 그것은 계획 단계에 있을 것이고, 개발자는 계획 단계에서 작업 할 무언가를 찾고, 빌드하고, 그래서 그들은 코드를 작성하고 그 코드에서 빌드를 만들 것입니다. 그리고 그들은 그것을 테스트합니다. 그래서 그들은 코드가 올바르게 작동하는지 확인하는 작은 스크립트를 읽었습니다. 두 개의 숫자를 더하는 함수를 만드는 경우 예상치 못한 결과로 전달할 수 있습니다. 결과는 4입니다. 그리고 그것은 당신의 기능이 올바르게 작동하고 있다는 좋은 표시가 될 것입니다.

따라서 1 단계와 3 단계는 매우 연결되어 있습니다. 마지막에 작성된 테스트는 본질적으로 사양을 코드화 합니다. 커피 메이커를 만드는 데 성공한 것은 5 초 안에 가열되어야 합니다. 그래서 그것에 대한 테스트를 작성하십시오. 커피를 추출하는 데 충분한 강도가 없어야 하므로 이에 대한 테스트를 작성하십시오. 테스트 주도 개발은 3 단계 중 1 단계의 유사성을 사용하여 이 프로세스를 뒤집습니다. 따라서 먼저 개발자는 작업 할 무언가를 선택합니다. 그런 다음 코드를 읽기 전에 테스트를 작성합니다. 따라서 그들은 사양이 충족되지 않아 현재 실패한 테스트를 작성합니다. 그런 다음 2 단계에서 작성한 모든 사양이 충족 될 때까지 코드를 작성합니다. 따라서 그들은 커피 메이커가 성공하면 효과가 있는 테스트 요법을 만든 다음 가장 저렴한 커피 메이커를 만들 수 있습니다.

그리고 최종 결과는 동일합니다. 따라서 소프트웨어가 구축되고 테스트되고 사양과 일치합니다. 그러나 많은 경우 코드를 작성하는 것이 훨씬 쉽습니다. 무엇을 구축하고 있는지 알고 있기 때문에 먼저 테스트를 작성하고 작업해야 할 중요한 사항과 나중에 변경할 사항에 대해 생각해야 합니다.

그래서 이것은 테스트에 대해 논의하는 매우 빠른 비디오입니다. 다음 비디오에서는 지속적인 통합에 대해 이야기 할 것입니다. 이것이 바로 이 아이디어의 DevOps 연속입니다. 거기서 보자.

그래서 우리는 개발자가 코드를 만든 후 향후 몇 년 동안 코드가 계속 작동하는지 확인하는 스크립트를 읽는 테스트에 대해 이야기했습니다. 그리고 그것은 사람들이 DevOps 맥락에서 이야기하는 큰 주제 중 하나 인 ci에 대한 논의로 이어집니다. 그리고 CI는 지속적인 통합을 의미합니다. 이는 개발자가 하루에 여러 번 작은 변경 사항을 중앙 저장소에 지속적으로 푸시하는 것을 의미합니다. 그리고 이러한 변경 사항은 프로그래머가 정의한 테스트를 실행하는 자동화 된 컴퓨터 소프트웨어에 의해 확인됩니다.

그래서 우리는 테스트가 무엇인지 살펴 보았습니다. 그렇다면 회사에서 CI를 사용하는 이유에 대해 이야기 해 봅시다.

CI는 DevOps 자동화의 첫 번째 단계입니다. 한 명의 개발자가 소규모 사용자 그룹이 사용할 프로그램을 만드는 가장 간단한 시나리오를 상상해보십시오.

그 개발자는 원래 프로그램을 릴리스하고 프로젝트는 천천히 견인력을 쌓습니다.

이제 개발자가 1 년 후 심각한 버그를 가지고 있다고 상상해보십시오.

그리고 그들은 예전 코드로 돌아가서 이렇게 말합니다. 이건 정말 나쁜 코드입니다. 저는 1 년 전부터 더 나은 프로그래머가되었습니다. 나는 여기서 무슨 일이 일어나고 있는지 정말로 이해하지 못합니다. 그러나 그것이 실제로 개발이 작동하는 방식입니다. 프로그래머는 해마다 더 좋아집니다. 그리고 그들은 1 년 전에 작성한 잘못된 코드를 읽고 이해해야 합니다. 1 년이 지난 레거시 코드를 자신 있게 변경할 수 있는 유일한 방법은 CI를 사용하는 것입니다.

ci는 기존 기능의 손상에 대해 걱정할 필요 없이 자신 있게 새로운 변경을 수행 할 수 있기 때문에 개발자 속도를 향상 시킵니다. 테스트가 통과하는 한 ci는 고객 이탈도 감소시킵니다. 소프트웨어의 문제는 발생할 가능성이 훨씬 적습니다. 자동으로 실행되는 포괄적 인 테스트가 있는 경우. 이러한 확인 표시가 있는 한 애플리케이션의 핵심 기능이 계속 작동 할 것이라고 합리적으로 확신 할 수 있습니다. 그렇다면 CI를 개발 프로세스에 어떻게 통합 하시겠습니까? 먼저 많은 개발 팀이 사용하는 공통 분기 기반 개발 프로세스에 대해 이야기 해 보겠습니다. 따라서 먼저 개발자는 기능 브랜치에서 작업합니다. 따라서 고객은 특정 시간에 고객에게 표시되는 최신 파일을 가져 와서 분기합니다. 따라서 그들은 다양한 구성 요소를 변경하는 작업을 수행하는 다른 모든 개발자와 독립적으로 자신의 기능에 대해 작업 할 파일의 새 복사본을 만듭니다. 따라서 이 기능은 모바일 앱과 웹 사이트를 변경합니다.

그런 다음 해당 브랜치에서 저장소로 다시 푸시합니다. 저장소는 일반적으로 GitHub, git lab 또는 Bitbucket과 같습니다. 그런 다음 해당 저장소는 ci를 실행하므로 CI는 저장소 측에서 구성되고 프로그래머가 정의한 모든 테스트를 실행합니다. 그런 다음 해당 테스트의 결과가 풀 요청에 첨부됩니다. 그리고 풀 요청은 개발자가 코드를 가져와 사용자에게 표시 될 중앙 저장소에 병합하도록 요청하는 것입니다. 여기에 기능 브랜치를 가져 가면 마지막에 입력하고 사용자에게 표시되는 다른 모든 커밋을 표시합니다. 이제 이 커밋은 다음 번에 사용자에게 표시되는 커밋이며 다음 번에 배포 할 때 프로그래머가 만나는 기능이 사용자에게 표시됩니다. 그리고 가장 좋은 부분은 GitHub, git lab 및 Bitbucket과 같은 중앙 Git 리포지토리에 비용이 들지 않는다는 것입니다.

대부분의 조직은 보안 및 액세스 제어를 제외한 조직의 경우에도 필요한 권한 기능을 제공합니다. 규모를 확장하고 계층 ci, GitHub 작업, git lab 파이프 라인과 같은 ci 공급자도 모두 관대 한 기능을 갖습니다. 아시다시피 이들의 CI는 웹 사이트에서 작업하는 사람들을 위해 만들어졌습니다. 아마도 고려할만한 사항 일 것입니다. 그러나 프로젝트 수명주기의 초기 단계에 있다면 어떤 CI 공급자를 사용할지는 중요하지 않습니다. 물론, ci에 대한 논의에서 빼놓을 수 있는 한 가지가 있습니다. 그것은 ci가 중요한 도구라는 것입니다. 이것은 대부분의 pull request 자동화 체계에서 자동화되어야 하는 첫 번째 것입니다. 너무 쉽기 때문에. 개발자는 이러한 테스트를 작성해야 합니다. 따라서 자동으로 테스트를 실행하지 않으면 사람들은 자신이 깨고 있다는 사실을 깨닫지 못하고 문제를 깨뜨릴 것입니다. 그리고 사용자는 그 깨진 것들을 알아 차릴 것입니다.

-----------

https://www.freecodecamp.org/news/devops-engineering-course-for-beginners/