🥇CI/CD로 전환할 때 가장 흔히 저지르는 XNUMX가지 실수

귀하의 회사가 DevOps 또는 CI/CD 도구를 도입하는 경우, 반복하지 않고 다른 사람의 갈퀴를 밟지 않도록 가장 일반적인 실수를 익히는 것이 도움이 될 수 있습니다.

팀 Mail.ru 클라우드 솔루션 기사를 번역했습니다 CI/CD로 전환할 때 이러한 일반적인 함정을 피하세요. 작성자: Jasmine Chokshi with Additions.

문화와 프로세스 변화에 대한 준비가 부족함

순환도를 보면 개발자, DevOps 관행에서 테스트는 모든 단일 배포의 기본 부분인 지속적인 활동이라는 것이 분명합니다.

DevOps 무한 주기 차트

개발 및 제공 중 테스트와 품질 보증은 개발자가 수행하는 모든 작업에서 필수적인 부분입니다. 이를 위해서는 테스트를 모든 작업에 통합하기 위한 사고방식의 전환이 필요합니다.

테스트는 모든 팀 구성원의 일상 업무의 일부가 됩니다. 지속적인 테스트로 전환하는 것은 쉽지 않으므로 이에 대비해야 합니다.

피드백 부족

DevOps의 효율성은 지속적인 피드백에 달려 있습니다. 협업과 소통의 여지가 없으면 지속적인 개선은 불가능합니다.

회고적 회의를 조직하지 않는 기업은 CI/CD에 지속적인 피드백 문화를 구현하기가 어렵습니다. 각 반복이 끝날 때마다 회고 회의가 열리며, 이 동안 팀원들은 잘 된 점과 나빴던 점을 논의합니다. 회고적 회의는 Scrum/Agile의 기초이지만 DevOps에도 필요합니다.

회고적인 모임은 피드백과 의견을 교환하는 습관을 심어주기 때문이다. 시작 시 가장 중요한 점 중 하나는 반복되는 복고풍 회의를 팀 전체가 이해하고 친숙할 수 있도록 구성하는 것입니다.

소프트웨어 품질에 관해서는 모든 팀원이 이를 유지할 책임이 있습니다. 예를 들어, 개발자는 단위 테스트를 작성하고 테스트 가능성을 염두에 두고 코드를 작성하여 처음부터 위험을 줄일 수 있습니다.

테스트에 대한 생각의 변화를 반영하는 간단한 방법 중 하나는 QA가 아닌 소프트웨어 테스터 또는 품질 엔지니어에게 테스터를 호출하는 것입니다. 이 변화는 너무 단순하거나 심지어 어리석어 보일 수도 있습니다. 그러나 누군가를 "소프트웨어 품질 보증 담당자"라고 부르는 것은 제품 품질에 대한 책임이 누구에게 있는지에 대한 잘못된 생각을 갖게 됩니다. Agile, CI/CD 및 DevOps 방식에서는 모든 사람이 소프트웨어 품질에 대한 책임을 집니다.

또 다른 중요한 점은 전체 팀과 각 구성원, 조직 및 이해관계자에게 품질이 무엇을 의미하는지 이해하는 것입니다.

무대 완성에 대한 오해

품질이 지속적이고 일반적인 프로세스라면 단계 완료에 대한 공통된 이해가 필요합니다. 무대가 언제 끝났는지 어떻게 알 수 있나요? Trello 또는 기타 Kanban 보드에서 단계가 완료로 표시되면 어떻게 되나요?

DoD(완료 정의)는 CD DevOps/CI의 맥락에서 강력한 도구입니다. 이는 팀이 무엇을 어떻게 구축하는지에 대한 품질 표준을 더 잘 이해하는 데 도움이 됩니다.

개발팀은 "완료"가 무엇을 의미하는지 결정해야 합니다. 그들은 완전한 것으로 간주되기 위해 각 단계에서 충족해야 하는 특성 목록을 작성해야 합니다.

DoD는 모든 팀 구성원이 이해하고 상호 동의하는 경우 프로세스를 더욱 투명하게 만들고 CI/CD 구현을 더 쉽게 만듭니다.

현실적이고 명확하게 정의된 목표가 부족함

이것은 가장 자주 인용되는 조언 중 하나이지만 반복해서 언급할 가치가 있습니다. CI/CD 또는 DevOps를 포함한 주요 노력에서 성공하려면 현실적인 목표를 설정하고 이에 대한 성과를 측정해야 합니다. CI/CD를 통해 무엇을 달성하려고 하시나요? 이를 통해 더 나은 품질로 더 빠른 릴리스가 가능합니까?

설정된 모든 목표는 투명하고 현실적이어야 할 뿐만 아니라 회사의 현재 활동과도 일치해야 합니다. 예를 들어, 고객에게 새 패치나 버전이 얼마나 자주 필요합니까? 사용자에게 추가적인 이점이 없다면 프로세스에 과부하를 걸고 더 빨리 릴리스할 필요가 없습니다.

또한 항상 CD와 CI를 모두 구현할 필요는 없습니다. 예를 들어, 은행, 병원 등 규제가 엄격한 회사는 CI로만 작업할 수 있습니다.

CI는 DevOps를 구현하는 모든 회사의 좋은 출발점이 됩니다. 이것이 구현되면 소프트웨어 제공에 대한 기업의 접근 방식이 크게 달라집니다. CI가 마스터되면 전체 프로세스 개선, 출시 속도 향상 및 기타 변경 사항을 고려할 수 있습니다.

많은 조직에서는 CI만으로도 충분하며 CD는 가치를 더하는 경우에만 구현해야 합니다.

적절한 대시보드 및 지표가 부족함

목표를 설정하면 개발팀은 KPI를 측정하기 위한 대시보드를 만들 수 있습니다. 개발하기 전에 모니터링할 매개변수를 평가하는 것이 좋습니다.

다양한 보고서와 애플리케이션은 다양한 팀 구성원에게 유용합니다. 스크럼 마스터는 지위와 도달 범위에 더 관심이 있습니다. 고위 경영진은 전문가의 소진율에 관심이 있을 수 있습니다.

또한 일부 팀에서는 빨간색, 노란색 및 녹색 표시기가 있는 대시보드를 사용하여 CI/CD의 상태를 평가하여 모든 작업이 올바르게 수행되고 있는지 또는 오류가 있는지 파악합니다. 빨간색은 현재 일어나고 있는 일에 주의를 기울여야 함을 의미합니다.

그러나 대시보드가 표준화되지 않으면 오해의 소지가 있을 수 있습니다. 모든 사람에게 필요한 데이터가 무엇인지 분석한 다음 그 의미에 대한 표준화된 설명을 작성하세요. 그래픽, 텍스트, 숫자 중 이해관계자에게 더 적합한 것이 무엇인지 알아보세요.

수동 테스트 없음

테스트 자동화는 좋은 CI/CD 파이프라인의 기반을 마련합니다. 그러나 모든 단계에서 자동화된 테스트가 수동 테스트를 수행해서는 안 된다는 의미는 아닙니다.

효과적인 CI/CD 파이프라인을 구축하려면 수동 테스트도 필요합니다. 테스트에는 사람의 분석이 필요한 몇 가지 측면이 항상 있습니다.

파이프라인에 수동 테스트 노력을 통합하는 것을 고려해 볼 가치가 있습니다. 일부 테스트 사례의 수동 테스트가 완료되면 배포 단계로 이동할 수 있습니다.

테스트를 개선하려고 하지 마세요

효과적인 CI/CD 파이프라인을 위해서는 테스트 관리, 통합, 지속적인 모니터링 등 올바른 도구에 대한 액세스가 필요합니다.

강력하고 품질 지향적인 문화를 조성하는 것을 목표로 합니다. 테스트 구현, 배포 후 고객 상호 작용을 모니터링하고 개선 사항을 추적합니다.

다음은 쉽게 구현할 수 있는 몇 가지 실용적인 팁입니다.

테스트가 작성하기 쉽고 코드를 리팩터링할 때 중단되지 않을 만큼 유연한지 확인하세요.
개발팀은 테스트 프로세스에 포함되어야 합니다. CI 파이프라인 중에 테스트하는 데 중요한 사용자 문제 및 요청 목록을 참조하세요.
전체 테스트 범위를 확보할 수는 없지만 항상 UX 및 고객 경험에 중요한 흐름을 테스트하는지 확인하세요.

마지막으로 중요한 포인트

CI/CD로의 전환은 일반적으로 상향식으로 진행되지만 궁극적으로는 회사의 리더십 승인, 시간 및 리소스가 필요한 전환입니다. 결국 CI/CD는 일련의 기술, 프로세스, 도구 및 문화적 재구성이므로 이러한 변화는 체계적으로만 구현될 수 있습니다.

주제에 대해 더 읽을 내용:

출처 : habr.com

CI/CD로 마이그레이션할 때 가장 흔히 저지르는 XNUMX가지 실수