Этот пост был первоначально опубликован на программном обеспечении OpenMake интернет сайт .
Итак, вы современная фабрика программного обеспечения, и вы принимаете DevOps. Вы знаете, что первое, что вам нужно иметь, — это непрерывный процесс доставки. В конце концов, вы не можете считать, что у вас есть гибкая практика DevOps без постоянной доставки. Таким образом, вы настроили процесс CI/CD для своих разработчиков и получаете полученные сборки автоматически на SET. Там проходят некоторые автоматические тесты, и сборка получает зеленый свет (или нет, как может быть, может быть).
Вы должны были установить агенты на каждом сервере в среде SIT, но это было не слишком обременительно — было всего 10 машин. И у вас есть настройка мониторинга, чтобы убедиться, что агенты всегда работают. Так что там нет проблем, верно?
Затем однажды ваш босс приходит к вашему столу. «Я читал о DevOps, говорит он, — и мы должны быть в состоянии подтолкнуть UAT, если код пройдет автоматические тесты in sit, верно? Это должно сэкономить нам время ».
Итак, вы улыбаетесь и говорите «конечно». Но теперь у вас есть проблема. Есть несколько среда UAT, и развертывание может пойти на любое из них. Итак, теперь у вас есть еще 20 машин для установки агентов. Половина виртуально, и половина физическая, но вы делаете это и создаете мониторинг. Конечно, мониторинг начинает предупреждать каждый раз, когда виртуальный сервер выключается, поэтому вы прекращаете контролировать эти серверы. Но затем половина времени агент не запускается должным образом, когда виртуальный сервер поднимается — и вы обнаружите это только тогда, когда автоматизированное развертывание не удается.
Тем не менее, это не так уж плохо. Сейчас у вас есть 30 агентов по развертыванию, только 20 из которых контролируются, и иногда автоматическое развертывание в виртуализированную среду UAT потерпит неудачу, поскольку агент не работает. Но в целом, вы можете жить с этим.
Тогда вас вызывают на встречу. Команда UAT решила, что они собираются переместить все в облако. Это позволит им быть более гибкими, поскольку они могут просто раскручивать сервер, когда им это нужно, чтобы справиться с повышенным спросом из -за всех новых сборки, которые нуждаются в тестировании. Конечно, каждый виртуализированный облачный сервер нуждается в установке агента, но вы можете справиться с этим, верно?
Таким образом, вы устанавливаете агенты на каждом из виртуализированных серверов, написав команды PowerShell для загрузки агента при запуске. Конечно, развертывание в этих средах не может происходить до тех пор, пока агент не работает, так что это немного замедляет процесс, но он все еще искажен, верно?
Затем ваш инструмент развертывания получает обновление. И это вносит изменение всем необходимым агентам. Сколько у вас снова? Где они установлены?
Тем не менее, вы на вершине вещей. У вас есть приличная практика DevOps. Все, что вам нужно сейчас, это последний толчок, чтобы перейти от непрерывной доставки к непрерывному развертыванию. Как только это будет сделано, вы достигли вершины модели зрелости DevOps, и у вас есть автоматизированные развертывания вплоть до производства.
Итак, вы идете поговорить с производственной поддержкой. И вы объясняете, что хотите установить кусок программного обеспечения на их критически важных серверах, которые могут внести изменения в любое производственное программное обеспечение на машине. И это черный ящик, поэтому вы не знаете, какой протокол он общается или в безопасности. И через десять минут вы покидаете встречу, когда ваши уши все еще звонят.
Таким образом, вы никогда не реализуете постоянное развертывание, так как у вас нет возможности автоматизировать развертывание в производство. Но эй, у тебя все еще есть гибкое решение, верно?
Затем принято решение на аутсорсинг инфраструктуру ИТ. Теперь вы больше не используете Windows Server 2012 и Redhat Linux. Теперь вы на Windows Server 2016 и Oracle Linux. Агент совместим с Oracle Linux? Вы быстро звоните продавцу, который говорит, что он должен работать (Oracle Linux — это просто Redhat, верно?) Но это не сертифицировано. Так что, если это не по какой -либо причине, вам не повезло.
В рамках этого сдвига также принимается решение установить DataPower для балансировки нагрузки. Изменения конфигурации должны быть доставлены в DataPower как часть процесса развертывания. Конечно, нет такой вещи, как «агент для веб -устройства, такой как DataPower, поэтому эти изменения должны применяться вручную. Такие изменения должны быть скоординированы с процессом автоматической доставки программного обеспечения. Но с электронными таблицами и электронной почтой можно было бы настроить что -то, что не так уж плохо.
Затем присоединяется новый главный архитектор программного обеспечения. Он молод и амбициоз и любит звуки микро-сервисов и контейнеров. Поэтому он решает запустить проект, который разбивает базу монолитного кода на кучу микро и мини -услуг, размещенных в различных контейнерах. Разработчикам нравится эта идея (отлично смотрится на их резюме!) Теперь ваше развертывание должно потенциально нацелиться на множество различных контейнеров Docker. Можете ли вы установить агент в контейнер? Будет ли это даже практично?
На данный момент вы внимательно рассматриваете свою новую инфраструктуру с ее балансировщиками и контейнерами нагрузки, а также сочетание физических, виртуальных и облачных серверов и решаете, что ваши агенты по развертыванию были действительно плохой идеей.
Агенты — враг Agile
Если этот кошмар звучит вам знакомо, вы не одиноки. Агенты — враг Agile. Они ограничивают, где можно выполнить развертывание и на какой платформе. Им нужен мониторинг, чтобы убедиться, что они работают. Они должны быть обновлены. Они должны быть установлены на каждой цели — даже облачные серверы. У некоторых облачных провайдеров есть свои собственные решения для развертывания, которые вам необходимы для интеграции с вашим агентом либо бесполезным, либо неизлечимым. И — хуже всего — это борьба за то, чтобы убедить производственную поддержку, чтобы позволить их установить в производственную среду. Это означает, что вы не только должны выполнить процесс развертывания ручного развертывания в той самой среде, в которой требуется автоматизированный, повторяемый, контролируемый и проверенный процесс — в производство — но вы никогда не достигнете постоянного развертывания, что является целью DevOps в первую очередь Анкет
Решения автоматизации выпуска приложений, которые используют агенты, также имеют тенденцию платить за них. Нельзя видеть инструменты, продаваемые лицензированием каждой конечной точки развертывания. Когда вы развертываете на физических серверах, это приемлемо. Но в настоящее время участки переходят в контейнеры и облачную инфраструктуру, чтобы они могли вращаться потенциально сотни серверов, чтобы соответствовать краткосрочным тестам. Модель лицензирования с использованием агентов не может быть в курсе такого рода процесса гибкого тестирования.
Вот почему современные решения ARA не используют агентов. Работа над открытыми протоколами, такими как SSH или FTPS, также имеет ряд других преимуществ:
Порты уже открыты. Как правило, нет никаких изменений брандмауэра для связи с целью развертывания.
Вы можете развернуться в производстве, так как самые порты, открытые для администрирования производственных серверов, представляют собой те же порты, которые используются для развертывания изменений. Непрерывное развертывание теперь становится возможным без необходимости установить «программное обеспечение Black Box в производственные серверы.
Вы можете ориентироваться на любую операционную систему, при условии, что она работает над этими открытыми протоколами. Хотите развернуть на мэйнфрейме, Iseries, Linux, Windows, OpenVMS и тандем из одного решения ARA? Затем выберите инструмент, который работает без агентов.
Хотите изменить конфигурацию на Web -Pappliance по сравнению с API на основе RESTFUL или SOAP? Нет агента, без проблем — предоставить изменение по API и записать его как успешную доставку компонентов.
Вывод
Агенты развертывания несовместимы с подходом к гибкой разработке и тестированию. Скомпрометируя способность обеспечить постоянное развертывание, они также являются врагами DevOps. Короче говоря, если вы хотите добиться полного потенциала Agile; Если вы хотите внедрить зрелое решение DevOps с постоянным развертыванием в производство; Если вы хотите сократить свои затраты и время простоя — Потеряйте свои агенты Анкет
Оригинал: «https://dev.to/philgibbs/agents-are-the-enemy-of-agile»