Действительно ли ваши инструменты CICD и DevOps помогают разработчикам?
14 февраля 2023 г.Если вы отвечаете за инструменты CICD и DevOps своей команды, задавались ли вы когда-нибудь вопросом, действительно ли созданные вами инструменты облегчают жизнь разработчикам? Или они просто усиливают установленные вами правила?
Вы несете ответственность за то, чтобы реализованные вами инструменты и процедуры действительно помогали разработчикам программного обеспечения выполнять свою работу.
Как часто после настройки инструментов CICD вы обращались к разработчикам за отзывом? Сколько раз вы меняли/обновляли их на основе отзывов разработчиков? Или все ваши изменения направлены на поддержку новых требований, инфраструктуры и инструментов анализа?
Вы можете подумать: "Мои инструменты выполняют анализ кода и автоматические тесты, поэтому они помогают разработчикам выявлять ошибки на ранней стадии".. Но так ли это?
Я обнаружил, что одной из основных причин ошибок во многих моих проектах является то, что разработчики тестируют свой код только локально. Моим обычным ответом на это был вопрос «Почему вы не выполняете развертывание в среде разработки, чтобы протестировать ее?». Это улучшит ситуацию на некоторое время, а затем вернется та же проблема.
Затем, через некоторое время, я решил изменить свой подход и спросить разработчиков, что они думают об имеющихся у нас инструментах DevOps, и услышал следующие комментарии:
* Анализ кода и автоматизация тестирования — это хорошо, но нужны ли они нам только для развертывания в среде разработки? * Конвейер для развертывания в среде разработки иногда занимает 15 минут. * Мне постоянно приходится ждать, пока другие разработчики закончат свои тесты, прежде чем я смогу развернуть свой код в среде разработки.
Сначала было нелегко признать, что я не замечал эти болевые точки, но я решил принять это и начал их решать.
Во-первых: максимально упростите развертывание в среде разработки
У меня уже были все проверки в запросах на вытягивание и в других средах. Итак, для среды разработки давайте просто упростим сборку и развертывание.
Далее: давайте сократим время, распараллелив все возможные задания
Ненужные задания уже удалены, но, возможно, мы сможем параллельно развернуть бэкенд и внешний интерфейс, а также любые другие задания, которые также необходимо выполнить.
Наконец: почему у вас только одна среда разработки? Как насчет автоматизации создания среды?
Для этого вы можете интегрировать его с вашим инструментом управления проектами. Каждый раз, когда разработчик переводит карточку в состояние «в процессе», он может автоматически создавать новую среду. Для этого вам, конечно же, понадобится инфраструктура как код.
После этих изменений развертывания в среде разработки стали более частыми, а качество улучшилось. Но разработчики изменили свое отношение не только потому, что развертывание было быстрее, а потому, что они чувствовали, что их слышат, и они могли видеть действия, вызванные их отзывами, и это мотивировало их вносить больший вклад в поиск решений для проблемы, которые у нас были.
И помните, что представленные здесь кейсы — это всего лишь примеры, это были болевые точки некоторых моих разработчиков. Это может быть не то же самое для вашей команды.
Важно узнать мнение вашей команды.
Находят ли они инструменты и процессы удобными и полезными или они вызывают у них головную боль?
Подумайте об этом — инструменты CICD должны поддерживать разработчиков, а не контролировать их. Вот почему так важно регулярно получать информацию от разработчиков и следить за тем, чтобы ваши инструменты и процессы работали на них. Конечная цель – сделать процесс разработки как можно более плавным и беззаботным.
Также опубликовано здесь < /p>
Оригинал