Разрешено ли использование DevOps компаниям с продуктами SaaS?

Практики, описывающие DevOps, такие как непрерывная доставка, автоматизация и т. Д., Имеют отношение к продуктам, которые обеспечивают непрерывное обслуживание, таким как продукты SaaS.

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

Распространяется ли DevOps на компании, разрабатывающие несколько разовых проектов? Какие практики DevOps применяются в этом случае, если вообще применяются?

Точно нет!

DevOps - это разрушение традиционных хранилищ (отделов) с целью повышения их эффективности.

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

Я работал в крупной медиа-компании, где мы поддерживали внутренний инструмент и разрабатывали общедоступные веб-сайты.

Преимущества DevOps в нашем случае были следующими:

• Благодаря непрерывному построению мы сообщаем команде разработчиков раньше, а не позже, если есть проблемы с интеграцией или сборкой их кода. Они могут исправлять проблемы, пока их ум все еще занят фрагментом кода, который они только что зафиксировали.
• Благодаря непрерывному тестированию и доставке (в QA) мы позволили команде QA раньше находить проблемы и сообщать о них раньше. Это сократило время, необходимое для поиска и исправления ошибок, а также уменьшило сложность этих исследований.
• С помощью инструментов сбора и агрегации журналов мы предоставили разработчикам доступ к тому, на что они обычно не обращали внимания (они были очень заинтересованы в отладчиках :) - понимание того, как журналы видятся и используются другими командами, улучшило общее качество журналов.
• Мы часто обменивались информацией и создавали документацию для обмена знаниями между командами, пытаясь разрушить стены. Понимая потребности Ops, мы создаем несколько руководств, о которых всегда следует помнить при начальной загрузке приложения (где / как управлять свойствами и т. Д.). Понимая реальность Dev (код больше возможностей, быстрее, gogogogo!), Мы смогли заставить операторов создавать серверы и кластеры, которые лучше подходили для нужд разработчика.
• Общее качество развертываний также значительно улучшилось. Развертывания были обработаны нашей командой, поэтому мы отлично видели как Ops, так и Dev. Это устранило много проблем, связанных с «передачей кода», когда разработчик передавал пакет и одностраничный документ оператору с надписью «Install this!».

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

Моя команда и я отвечаем за разработку «одноразовых» продуктов, которые после завершения работы передаются клиенту для обслуживания или, в некоторых случаях, управляются нами за плату.

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

Хотя клиенту не важны DevOps (в большинстве случаев), он по-прежнему полезен для нас. Благодаря DevOps мы можем быстро загружать новые сборки, чтобы клиенты могли видеть отзывы в течение нескольких минут, а не часов, и мы также можем выявлять любые ошибки / ошибки при тестировании через Jenkins / Travis.

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

Затраты, сэкономленные DevOps, определить сложно. У нас есть дополнительные расходы в виде программного обеспечения, которое мы выбираем для использования в процессе разработки (Трэвис, Дженкинс, Пуппет, что у вас есть), но мы также экономим время и деньги, исправляя ошибки / быстро предоставляя обратную связь клиентам. Наше быстрое время отклика делает наших клиентов счастливыми, а наши кошельки - счастливыми.

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

• Автоматизированные воспроизводимые сборки программного обеспечения с известными контролируемыми конфигурациями компиляторов, библиотек и других инструментов сборки.
• Автоматизированные, повторяемые системные тесты для регрессионного тестирования и новых функциональных тестов.
• Другие автоматизированные и регулярные действия (например, постоянно обновляемые примеры снимков экрана, доступных на всех поддерживаемых языках, для проверки переводчиками и для включения в технические руководства технических авторов).

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

Деятельность по разработке и внедрению программного обеспечения ранее не требовала глубокой интеграции между отделами. Но на сегодня необходимо тесно сотрудничать со всеми отделами (разработка, ИТ-операции, обеспечение качества и т. Д.).

Для разработчиков изменения - это то, за что им платят. Бизнес всегда нуждается в изменениях, чтобы соответствовать современному миру. Это понимание подталкивает разработчиков к созданию максимально возможного количества изменений. ИТ-специалисты имеют другое понимание, в котором изменения вредны. Каждый из них считает, что работает правильно, принося пользу бизнесу. Действительно, если мы рассмотрим их по отдельности, они оба правы.

Все сотрудники должны понимать, что они являются частью единого процесса. DevOps развивает мышление, что позволяет понять, что личные решения и действия каждого должны быть направлены на реализацию единой цели. И успех должен измеряться относительно всего цикла разработки от поставки, а не от успеха отдельных ролей. В результате тесного сотрудничества между разработчиками и специалистами по техническому обслуживанию формируется новое поколение инженеров, которые используют лучшие достижения обеих дисциплин и объединяют их на благо пользователя. Это проявляется в появлении межфункциональных команд с опытом разработки, управления конфигурациями, управления базами данных, тестирования и управления инфраструктурой.

Так что методология полезна не только в SaaS.

Не за что. Хотя в этой теме уже есть отличные примеры, я хотел бы поделиться собственным анекдотом. В 2001 году я унаследовал программный проект с выпуском компакт-диска. Документация по процессу выпуска включала 40 (!) Шагов, задокументированных предыдущим инженером, которые включали в себя несколько нелепых рукописных инструкций, таких как «открыть этот файл конфигурации и изменить имя файла .jar в строке 41, чтобы включить номер версии новый выпуск ".

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

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

У нас, конечно, есть более тесные петли обратной связи, когда мы можем развернуть программное обеспечение как услугу, но все основные принципы автоматизации, обратной связи, времени цикла, небольших выпусков и т. Д. Все применимы.