Решение кейса #4 Что делать в этой ситуации?

В прошлом посте мы разобрали три главных ошибки команды, в которой захотели настроить Jenkins, потратили два месяца и более $30k.

Сегодня мы поговорим о том, как этих ошибок можно было бы избежать.

Мысль #1. Карго-культ

Возможно заказчик компании К действительно оправданно использовал Jenkins для автоматизации своих процессов по разработке приложений.

Но это не значит, что самой компании К он был необходим для реализации конкретных задач - формирование артефактов и передача их между шагами одного пайплана.

Команда построила соломенный самолет, который не мог взлететь. Как говорится, не сотвори себе кумира.

Мысль #2. Постановка задачи консультанту

Консультант по автоматизации мог бы помочь в этой ситуации, если бы запрос сформулировали не как "нам нужен Jenkins", а "нам нужно, чтобы наши пайплайны умели передавать артефакты между шагами, и мы хотим уметь откатывать изменения на сервере, используя предыдущий артефакт, какие инструменты для этого нам лучше использовать?".

Какие инструменты инструменты для этого нам лучше использовать? Вот тот вопрос, который надо было задать самим себе.

Мысль #3. Порог чувствительности реагирования

Если что-то идет не так, нужно реагировать. Не нужно ждать два месяца, пока проблема сама рассосется.

Это вряд ли произойдет. Уже в первую неделю использования, если что-то пошло не так, нужно выносить вопрос на обсуждение.

—

Согласны? Поделитесь мыслями в комментариях! 👇

🧘 Точка останова #решение

В этом посте были ссылки, но мы их удалили по правилам Сетки