Ако вашата компания тепърва въвежда DevOps или CI/CD инструменти, може да е полезно да се запознаете с най-честите грешки, за да не ги повтаряте и да не стъпвате на чужд рейк.
Отбор преведе статията .
Неподготвеност за промяна на културата и процесите
Ако погледнете цикличната диаграма , ясно е, че в практиките на DevOps тестването е непрекъсната дейност, основна част от всяко отделно внедряване.
Графика на безкраен цикъл на DevOps
Тестването и осигуряването на качеството по време на разработката и доставката са съществена част от всичко, което разработчиците правят. Това изисква промяна в мисленето, за да се включи тестването във всяка задача.
Тестването става част от ежедневната работа на всеки член на екипа. Преходът към постоянно тестване не е лесен, трябва да сте подготвени за това.
Липса на обратна връзка
Ефективността на DevOps зависи от постоянната обратна връзка. Постоянното подобряване е невъзможно, ако няма място за сътрудничество и комуникация.
Компаниите, които не организират ретроспективни срещи, намират за трудно да въведат култура на непрекъсната обратна връзка в CI/CD. Ретроспективни срещи се провеждат в края на всяка итерация, по време на които членовете на екипа обсъждат какво е минало добре и какво е било лошо. Ретроспективните срещи са в основата на Scrum/Agile, но са необходими и за DevOps.
Това е така, защото ретроспективните срещи възпитават навика за обмен на обратна връзка и мнения. Един от най-важните моменти в началото е организирането на повтарящи се ретро срещи, така че да станат разбираеми и познати на целия екип.
Що се отнася до качеството на софтуера, всички членове на екипа са отговорни за поддържането му. Например, разработчиците могат да пишат модулни тестове и също така да пишат код с възможност за тестване, което помага за намаляване на риска от самото начало.
Един прост начин да се отрази промяната в мисленето за тестване е да се наричат тестерите не QA, а софтуерен тестер или инженер по качеството. Тази промяна може да изглежда твърде проста или дори глупава. Но наричането на някого „лице за осигуряване на качеството на софтуера“ дава грешна представа за това кой е отговорен за качеството на продукта. В практиките Agile, CI/CD и DevOps всеки е отговорен за качеството на софтуера.
Друг важен момент е да разберете какво означава качество за целия екип и всеки от неговите членове, организацията и заинтересованите страни.
Неразбиране на завършването на етапа
Ако качеството е непрекъснат и общ процес, е необходимо общо разбиране за завършване на етапа. Как да разберете, че етапът е приключил? Какво се случва, когато една стъпка е маркирана като завършена на Trello или друга Kanban дъска?
Определението за готово (DoD) е мощен инструмент в контекста на CD DevOps/CI. Помага за по-доброто разбиране на стандартите за качество на това какво и как изгражда екипът.
Екипът за разработка трябва да реши какво означава „Готово“. Те трябва да седнат и да направят списък с характеристики, които трябва да бъдат изпълнени във всеки етап, за да се счита за завършен.
Министерството на отбраната прави процеса по-прозрачен и улеснява внедряването на CI/CD, ако се разбира от всички членове на екипа и е взаимно съгласувано.
Липса на реалистични, ясно дефинирани цели
Това е един от най-често цитираните съвети, но си струва да го повторим. За да успеете във всяко голямо начинание, включително CI/CD или DevOps, трябва да си поставите реалистични цели и да измерите ефективността спрямо тях. Какво се опитвате да постигнете с CI/CD? Това позволява ли по-бързи версии с по-добро качество?
Всички поставени цели трябва да бъдат не само прозрачни и реалистични, но и съобразени с текущите дейности на компанията. Например, колко често вашите клиенти се нуждаят от нови корекции или версии? Няма нужда да претоварвате процесите и да освобождавате по-бързо, ако няма допълнителна полза за потребителите.
Освен това не винаги е необходимо да прилагате едновременно CD и CI. Например силно регулирани компании като банки и медицински клиники могат да работят само с CI.
CI служи като добра отправна точка за всяка компания, внедряваща DevOps. Когато се внедри, подходът на компаниите към доставката на софтуер се променя значително. След като CI бъде усвоен, можете да мислите за подобряване на целия процес, увеличаване на скоростта на внедряване и други промени.
За много организации само CI е достатъчен и CD трябва да се внедрява само ако добавя стойност.
Липса на подходящи табла и показатели
След като зададете целите си, екипът за разработка може да създаде табло за измерване на KPI. Преди разработването му си струва да се оценят параметрите, които ще се наблюдават.
Различните отчети и приложения са полезни за различните членове на екипа. Scrum Master се интересува повече от статус и обхват. Докато висшето ръководство може да се интересува от степента на прегаряне на специалистите.
Някои екипи също използват табла с червени, жълти и зелени индикатори, за да оценят състоянието на CI/CD, за да разберат дали правят всичко правилно или има грешка. Червеното означава, че трябва да обърнете внимание на случващото се.
Въпреки това, ако таблата за управление не са стандартизирани, те могат да бъдат подвеждащи. Анализирайте от какви данни се нуждае всеки и след това създайте стандартизирано описание на значението им. Разберете какво има повече смисъл за заинтересованите страни: графики, текст или числа.
Без ръчни тестове
Автоматизацията на тестовете полага основата за добър CI/CD конвейер. Но автоматизираното тестване на всички етапи не означава, че не трябва да провеждате ръчно тестване.
За да изградите ефективен CI/CD тръбопровод, имате нужда и от ръчни тестове. Винаги ще има някои аспекти на тестването, които изискват човешки анализ.
Струва си да обмислите интегрирането на усилията за ръчно тестване във вашия конвейер. След като ръчното тестване на някои тестови случаи приключи, можете да преминете към фазата на внедряване.
Не се опитвайте да подобрявате тестовете
Един ефективен CI/CD тръбопровод изисква достъп до правилните инструменти, било то управление на тестове или интеграция и текущ мониторинг.
Създаването на силна, ориентирана към качеството култура има за цел , наблюдение на взаимодействията с клиентите след внедряването и проследяване на подобрения.
Ето няколко практически съвета, които можете лесно да приложите:
- Убедитесь, что тесты просты в написании и достаточно гибки, чтобы не ломаться при рефакторинге кода.
- Екипите за разработка трябва да бъдат включени в процеса на тестване - вижте списък с потребителски проблеми и заявки, които са важни за тестване по време на CI конвейери.
- Може да нямате пълно тестово покритие, но винаги се уверете, че потоците, които са важни за UX и потребителското изживяване, са тествани.
Последен, но не на последно място важен момент
Преходът към CI/CD обикновено се движи отдолу нагоре, но в крайна сметка това е трансформация, която изисква лидерство, време и ресурси от компанията. В края на краищата CI/CD е набор от умения, процеси, инструменти и културно преструктуриране; такива промени могат да се прилагат само систематично.
Какво още да прочетете по темата:
- .
- .
- .
Източник: www.habr.com