Нам часто говорят, что существование DevOps Team является чем -то вроде антипаттерна или, действительно, «считается вредным», но только после того, как я увидел это в действии, некоторые из причин этого совета стали действительно ясными, и я подумал, что замечу некоторых из них здесь.
В «плохие старые времена» разработчики писали код и «бросают его через забор» в операционную команду, которые были хранителями инфраструктуры организации и отвечали за все развертывание и обслуживание программного обеспечения. Эта процедура, конечно, имела связанную стоимость, выплачивая операционной команде, чтобы прийти на работу ночью или на выходных, чтобы «присматривать за развертыванием». Чтобы снизить эту стоимость, процедуры «рутинного» развертывания и технического обслуживания могут даже быть переданы на аутсорсинг работникам с более низким уровнем в других частях мира.
Этот подход также также вызвал культурные перерывы, конечно, в том смысле, что разработчики не стимулировали «владеть» надежностью продукта, а операционные команды мало интересовались ускорением доставки функций, предпочитая посвятить свое внимание поддержке Целостность инфраструктуры, особенно когда это была единственная доставка, связанная с их соглашением о аутсорсингах.
К этому было добавлено увеличение времени цикла из-за необходимости «передачи» между различными командами, участвующими в получении функции от MacBook к производству, что усугублялось, когда команды, участвующие в передаче, имели разные цели и и Приоритеты и даже разные работодатели.
DevOps Revolution обещал решить все эти проблемы, выравнивая интересы разработчиков и операционных команд в судоходстве быстрее, а также более надежно.
Естественно, с тех пор, как отправляют больше функций, более надежно звучащих как отличная идея, многие организации решили получить старт на своем DevOps Journey Набирая специальную команду, чтобы установить их Способность DevOps Анкет DevOps Team Прибыл вооружен обширным арсеналом инструментов и поставил задачу создания тщательно продуманных трубопроводов, панели мониторинга с множеством метрик и развертываний в синем, зеленых и всех цветах радуги.
Проблема, конечно, заключается в том, что интересы DevOps Team не были лучше согласованы с таковыми из разработчиков функций, чем в команде OPS, были ранее. Итак, пока DevOps Team были заняты высокой точки зрения, только что перенесли свои оркестровки развертывания в последний инструмент дня и создали совершенно новую панель инструментов с каждым метрическим представлением о качестве кода, функциональные команды все еще были очень неясны в том, как развернуть и контролировать функции, которые они были созданы и были сведены к бросить код через забор в команду DevOps Анкет
Конечно, способ сломать заборы, заключается в том, что функциональные команды должны сами владеть процессами доставки и мониторинга. Уже не является неосторожным предположить, что команды разработчиков должны стремиться к созданию «Т-образных людей», с более глубокой функциональной экспертизой в одной области, такой как базы данных, тестирование или кодирование фронта, а также базовый уровень понимания всех задач Требуется для успешного предоставления функции. В современном мире, конечно, одной из этих компетенций является возможность создавать автоматизацию тестирования и развертывания, а также инфраструктура и мониторинг, или, другими словами, задачи, которые выполняются вновь созданными DevOps Team На другой стороне забора.
Оригинал: «https://dev.to/gavincampbell/throwing-code-over-a-different-fence-c80»