Не про девопс

Если читать позапрошлый пост про девопс, то может, наверное, показаться, что я считаю, что девопсы - бесполезные специалисты. Нет, конечно, я так не считаю.

Но раз уж у нас теперь есть понимание, что такое девопс на самом деле, надо задаться вопросом, а чем тогда занимаются инженеры, которых зовут девопсами?

И, если вы посмотрите внимательно, то увидите, что чаще всего это будет автоматизация развёртывания приложения в проде. И вопрос тут стоит уже иначе: а должно ли оно быть так? Ну то есть, нужен ли отдельный инфраструктурный инженер под это дело? Может, на самом деле, и нет вовсе никаких девопсов - просто взяли работу админа или разраба и отдали кому-то, назвав его специальность новым словом.

Ответ тут, как обычно, зависит от ситуации.

Где это нужно

Возьмем для примера условный Амазон. Есть ли там место инфраструктурным инженерам? Конечно! Там в нулевые целая платформа родилась, чтобы обеспечить внутренние потребности разработки инфраструктурой. Т.е. виртуалками. И инфраструктурным кодом, который их спавнит, редактирует и убивает.

Сейчас мы эту платформу знаем как полноценный продукт, AWS, на котором крутится, наверное, половина всего софта на западе.

То есть инфраструктурные инженеры, объединённые в платформенные команды, могут быть весьма полезны в определённых условиях.

Корректно ли их называть девопсами? Трудно сказать. Но сути их работы это не меняет.

А что, если вы берёте уже готовую чужую платформу в аренду (например, aws), а поверх начинаете чудить свою платформу?

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

Хорошо, а что если строить своё, как у AWS? Да, тут тоже без инфраструктурного инженера не обойтись. Но необходимо понимать, что у вас будет очень сильно хуже и очень сильно дороже, чем у Амазон.

Плохо ли это? Ну, если вам нельзя ни в AWS, ни в Яндекс облако по каким-то причинам, а продукт у вас толстенный и будет расти дальше, то это ваш путь.

Когда лучше без этого

Если у вас уже есть какая-то инфраструктурная платформа, то, честно говоря, специальный инженер, чтобы настроить деплой, не особо нужен. Платформы специально разрабатываются так, чтобы ими могли пользоваться разработчики.

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

И, в целом, это рабочая схема: программист программирует, тестировщик тестирует, девопс пишет пайпы. Потом дрожащими руками техлидов это кое-как соединяется в единый процесс, где все друг в друга кидаются тикетами в жире и какашками в общих чатах. Мы это видим почти везде.

Но можно же лучше?

И тут я, как обычно, вступаю в область идеального мира экстремального программирования, который встречается только у тех, кому не только повезло найти подходящую среду, но и они сами все сделали правильно, потому что знали, как надо.

Я уже упоминал в своих статьях про тестирование, что deployment pipeline - это не столько про поставку в прод, сколько про автоматическое тестирование всего, что можно протестировать до прода.

Ну то это есть, это не только прогнать юниты и собрать образы. Но ещё и поставить на стенды, прогнать там приёмочные е2е тесты, фронтовые тесты, нагрузочные тесты.

И только после этого уже ставить в прод уже проверенный билд проверенным скриптом с проверенной конфигурацией инфраструктуры. Или публиковать в маркетплейс, если это, например, мобилка.

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

Ну или не обнаружите, но это уже совсем другая и очень грустная история.