DevOps 기초(2/2): 단계 및 프로세스

지난 게시물에서 배운 것처럼 DevOps는 민첩한 작업 방식, 오토메이션 그리고 부서간 협업 기업에서 기존에 분산된 업무와 역할을 하나로 묶어 가치 창출을 위한 공통의 기반을 마련합니다. 즉, 이전에 개발 및 운영 팀에 할당된 작업이 이제 핵심 팀에 할당되어 반복해서 실행됩니다. 따라서 소위 말하는 “DevOps 라이프사이클”.

프로젝트는 DevOps로 어떤 단계를 거치나요?

이 주기에서 실행되는 단계는 말하는 사람에 따라 이름이 다른 경우가 많지만 결국 목표는 항상 같습니다. 이해하다. 그러나 여기에서 DevOps는 폐쇄적이고 지속적으로 진행되는 프로세스이며 여기에 설명된 단계는 원활하게 서로 얽혀 있다는 점을 언급해야 합니다.

계획

계획 단계에는 프로그램 코드의 실제 개발 이전에 발생하는 모든 일이 포함됩니다. 중앙에는 하나 로드맵, 제품 조정 구현을 계획하는 데 사용됩니다. 이러한 변경 사항은 사용자 피드백과 내부 요구 사항을 기반으로 할 수 있습니다. DevOps 파이프라인이 매핑되는 최신 도구에서 이러한 아티팩트는 서사시, 특징 그리고 사용자 스토리. 이로부터 스프린트가 계획되고 작업이 파생되며 다음 단계가 준비됩니다. 작업 계획 도구는 예를 들어 JIRA, Redmine 또는 EasyRedmine입니다. 요구 사항 관리 예를 들어 Fidelia로 수행할 수 있습니다.

암호

작업이 할당되면 개발 팀이 작업에 들어가 실제 프로그램 코드를 생성합니다. 진행 상황은 정기 회의(스탠드업 및 스프린트 검토)에서 팀에 전달됩니다. 모든 개발 팀이 동일한 방식으로 작업할 수 있도록 도구 및 플러그인에 대한 공통 기반과 단일 사양이 있습니다. 코드 품질. 코드 작성을 위한 IDE 외에도 소스 코드 관리 SCM Manager 등이 필요합니다. 또한 Confluence나 Smeagol과 같은 위키를 사용할 수 있습니다. 선적 서류 비치 코드의 도움.

짓다

작업이 완료되면 코드가 중앙 저장소에 커밋됩니다. 이 소위 푸시는 소위 풀 리퀘스트 하나에서 발동 코드 검토 모든 것이 정상이면 풀 요청이 확인됩니다. 병렬로 이미 찾기 자동화된 테스트 대신 가능한 오류에 대해 새 코드를 확인합니다. 이러한 테스트 중 하나가 실패하면 그에 대한 정보가 즉시 전송되고 코드가 개선될 수 있습니다. 모든 테스트를 통과하면 새 코드가 채택됩니다. 이 단계에서 하나는 필수 불가결 빌드 서버 젠킨스와 같은.

시험

빌드 단계에서 이미 실행된 테스트 절차 외에도 심층 테스트 또한 배포되는 자체 환경에서 발생합니다. 이 환경은 종종 다음과 같이 불립니다. “스테이지 환경” 지정된. 이 환경에서는 심층적인 자동 테스트 외에도 수동 테스트도 수행됩니다. 예를 들어 애플리케이션의 약점을 발견하기 위한 통합 및 보안 테스트가 될 수 있습니다. 또한 출판 전에 스테이징 환경에서 사용자 승인 테스트를 수행할 수도 있습니다. 테스트는 예를 들어 SonarQube 또는 Nexus Lifecycle로 수행할 수 있습니다.

풀어 주다

이러한 광범위하고 심층적인 테스트 절차가 완료된 후 출판물은 생산적인 환경 준비하기 위해. 이 시점에서 릴리스에 포함되어야 하는 변경 사항이 결정됩니다. 릴리스 프로세스의 성숙도에 따라 수동 또는 자동 단계가 될 수 있습니다. 일부 회사는 고정된 일정에 따라 새 버전을 릴리스하는 반면 다른 회사는 새 코드가 테스트 단계를 통과하면 자동으로 릴리스합니다. 고정된 사람이 하나의 역할을 수행하는 것이 가능합니다. 릴리스 관리자 할당됩니다. 버전 및 릴리스 관리를 위해 다음을 수행할 수 있습니다. 유물 저장소 관리 Nexus Repository와 같은 도구를 사용할 수 있습니다.

전개하다

이 단계에서 새 빌드의 실제 롤아웃이 발생합니다. 최신 도구를 사용하면 이제 자동화되고 진행 중인 작업을 중단하지 않고 가능한. 테스트 환경에서 이미 배포에 사용된 것과 동일한 코드를 여기에서 사용할 수 있습니다 – 키워드: 코드로서의 인프라. 배포 중에 예기치 않은 문제가 발생하면 문제 없이 생산 환경의 이전 상태를 일시적으로 복원할 수 있습니다. 예를 들어 Jenkins를 사용하여 자동 배포를 수행할 수 있습니다.

작동하다

이제 변경 사항이 적용되어 사용자가 사용할 수 있습니다. 이 단계에서는 운영을 주로 다루는 팀의 일부가 특히 중요한 역할을 합니다.

최신 도구는 자동으로 다음을 보장합니다. 효과적으로 차단된 최대 부하 프로덕션 환경을 효과적으로 운영하는 데 필요한 리소스를 항상 사용할 수 있습니다. 또한 고객은 팀에 피드백을 보낼 수 있습니다. 이것이 소프트웨어가 사용되는 방식과 사용자가 원하는 것에 대한 귀중한 통찰력을 얻을 수 있는 유일한 방법입니다. 이것은 가장 큰 성공 요인 중 하나이며 반드시 보장되어야 합니다!

감시 장치

사용자의 직접적인 피드백 외에도 사용 중에 발생하는 추가 데이터를 수집해야 합니다. 예를 들어 오류 발생, 대기 시간, 액세스 번호 그리고 개별 사용 행태 사용자가 되십시오. 직접적인 고객 피드백과 수집된 추가 데이터의 혼합은 다음 기능을 도출하기 위해 제품 관리자와 개발 팀으로 다시 흐를 수 있습니다. 이러한 방식으로 사용자가 진정으로 원하고 필요로 하는 것이 정확히 개발됩니다.

연속…모든 것!

처음에 언급한 이러한 단계는 진행 중인 프로세스이므로 DevOps 영역에서 일반적으로 로 축약되는 지속적인 통합, 지속적인 제공 및 지속적인 배포와 같은 키워드를 자주 접하게 됩니다. CI/CD. 이러한 용어의 의미와 위에서 언급한 단계에 어떻게 부합하는지 자세히 살펴보겠습니다.

지속적인 통합

핵심에서 지속적인 통합은 코드 변경을 의미합니다. 자주 정기적으로 공통 저장소에 통합되어야 합니다. 이것이 혁신적으로 들리지 않을 수도 있지만 DevOps 접근 방식의 모든 절차, 원칙 및 단계에 없어서는 안 될 기반을 형성합니다.

이러한 소규모 소프트웨어를 더 자주 통합하면 정기적으로 테스트 개별 부품의 복잡성이 줄어들고 오류/호환성 문제가 더 쉽고 빠르게 수정될 수 있습니다. 이것은 반드시 덜 디버깅 작동하다. 또한 팀의 변경 사항에 대한 가시성이 향상되고 향후 모든 변경 사항에 대한 지속 가능하고 견고한 기반이 마련됩니다.

자동화된 테스트 여기에서 이미 중요한 역할을 수행하므로 수동 테스트 노력이 줄어듭니다. 소프트웨어 부품의 더 빈번한 통합으로 인해 더 많은 버그가 분명히 발견되지만 프로그램 구성 요소가 더 작고 덜 복잡하기 때문에 수정하기가 훨씬 더 쉽습니다.

궁극적으로 이 접근 방식은 버그를 자동으로 발견하고 비용을 절감하며 전체 소프트웨어 주기를 보다 효율적으로 만드는 더 가볍고 반복 가능한 프로세스로 이어져야 합니다.

지속적 제공 및 지속적 배포

이 접근 방식이 지속적 통합을 기반으로 더욱 자동화되고 확장되는 경우 이를 지속적 전달이라고 합니다. 따라서 소프트웨어는 코드 기반에서 지속적으로 전달, 즉 배포될 수 있습니다.

코드가 모든 테스트 단계(유닛/통합/시스템 테스트)를 통해 성공적으로 실행되고 스테이징 환경에 성공적으로 배포된 경우 수동 릴리스버튼 하나만 누르면 생산적인 고객 환경으로 연결됩니다.

설령 그렇다 해도 승인 절차 생산 환경에 배포하기 위해 자동화되는 것을 연속 배포라고 합니다. 여기에서 여전히 수동 단계가 필요한 경우 지속적 전달에 대해 이야기합니다.

따라서 지속적인 배포는 최신 소프트웨어 개발의 궁극적인 목표이며 항상 지속적인 통합 및 지속적인 제공의 단계별 구현 및 개발로 이어집니다.

지속적인 피드백

마지막 핵심 요소는 기본 목표로 이해할 수 있습니다. 지속적인 피드백 시장과 사용자로부터 얻습니다. 궁극적으로 DevOps의 목표는 소프트웨어를 사용자의 손에 더 빨리 제공하여 새로운 기능이 어떻게 수신되고 있는지에 대한 직접적인 피드백을 받는 것입니다.

이 피드백은 다시 흐릅니다. 다시 개발 과정으로 따라서 팀의 추가 조치 과정을 크게 제어합니다. 이렇게 하면 소프트웨어 제품의 정렬 및 디자인에 대한 중요한 지침을 제공할 수 있고 제공해야 하는 효과적인 피드백 루프가 생성됩니다.

피드백만이 중요한 것은 아닙니다. 고객 평가, 예를 들어 커뮤니티 및 사용자의 직접적인 피드백을 통해 발생하지만 최신 DevOps 파이프라인이 제공하는 자동화된 메트릭도 있습니다. 예를 들어 업데이트를 제공하고 모니터링 도구에서 생산 서버의 CPU 및 메모리 사용률이 배달 이후 위험 수준으로 증가했다고 보고하는 경우 이는 팀의 다음 단계에 영향을 미치는 중요한 피드백이기도 합니다.

최신 DevOps 도구 체인은 DevOps 원칙에 따라 소프트웨어 개발을 훨씬 쉽게 구현할 수 있는 적합한 도구를 사용하여 이러한 모든 개념, 단계 및 절차를 지원합니다. 이를 위해 Cloudogu EcoSystem을 개발했습니다. 며칠 동안 긴 연구나 구성 작업을 할 필요가 없습니다. EcoSystem을 사용하면 단 30분 만에 자체 CI/CD 도구 체인을 설정할 수 있습니다. 문의하기!