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

26

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

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

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

Евгений
источник

Ответы:

32

Точно нет!

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

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

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

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

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

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

Александр
источник
1
Действительно, DevOps может применяться практически к любой организации разработки SW, даже к большим встраиваемым продуктам с небольшим количеством общедоступных выпусков в год - благодаря непрерывной доставке внутри конвейера разработки они все же могут получить некоторые преимущества DevOps: лучшее качество, снижение затрат, предсказуемость релизов и т. д.
Дан
Ответ напоминает SaaS, не очень хорошо объясняет, как продукт или услуга, не относящиеся к SaaS, могут извлечь выгоду из этих методов.
Евгений
Продукты, над которыми я работал, не были SaaS (как раз наоборот). Но обоснование остается прежним, не имеет большого значения, являетесь ли вы SaaS или нет, DevOps пытается улучшить продукт нетрадиционными способами. Я ничего не мог знать о нашей ценовой модели или предложении, это не имело бы такого большого значения.
Александр
13

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

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

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

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

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

черепаха
источник
Можете ли вы привести некоторые причины и преимущества того, почему это важно? На самом ли деле клиенты заботятся о вашем трубопроводе или только о готовом проекте в обещанные сроки и о цене, которую они должны заплатить? Не могли бы вы сократить расходы, не занимаясь всеми этими «девопсами» вещами? Не могли бы вы потратить больше времени на проект, не занимаясь этим, и получить больше денег для проектов (так как это дольше)?
Евгений
1
@Evgeny DevOps помогает завершить проект вовремя и в рамках бюджета по причинам, объясненным в моем ответе. Сокращая DevOps, вы также сокращаете преимущества, которые я объяснил. Сборка и тестирование часто помогают оставаться в рамках бюджета и в срок. Обнаружение ошибки позже стоит больше денег и занимает больше времени, это доказано много раз. Клиент не заботится о конвейере, но чем дольше вы ждете его отзывов, тем более затратным и длительным будет переписывание.
Александр
Разве это не Agile Software Dev?
Евгений
@ Евгений Я обновил свой ответ, чтобы уточнить. Мы используем Agile, но это не значит, что у нас не может быть менталитета
Turtle
1
@ Евгений, вероятно, вы могли бы сэкономить, не поддерживая свои юнит-тесты и приемочные тесты, но это создает технический долг, который является анти-паттерном DevOps. Вы можете избежать неприятностей в течение нескольких недель или месяцев, но вскоре вы (вероятно) столкнетесь с трудным в обслуживании беспорядком, который невозможно проверить.
Стив Баттон
3

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

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

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

Тоби Спейт
источник
Автоматизация не devops. Те же комментарии, что и в ответе Дэвида Бока ниже, наконец (извините, мой комментарий был утерян в момент, когда я проголосовал, только что заметил)
Tensibai
3

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

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

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

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

Quarind
источник
0

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

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

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

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

Дэвид Бок
источник
Это связано с автоматизацией, но никак не связано с организацией devops, я нигде не вижу упоминаний о команде по дисциплине plury, а просто автоматизирую то, что они наследуют
Tensibai
Это был 2001 год ... задолго до того, как появился DevOps. Это была не просто автоматизация, я считаю, что это упростило управление проектом точно таким же образом, что в конечном итоге стало называться «Культура» DevOps. Таким образом, это пример отношения DevOps вне организации SaaS.
Дэвид Бок
DevOps - это не автоматизация и не управление проектами. Речь идет о взломе основанной на бункере организации в корне. Извините, я не чувствую, что этот ответ действительно относится к Вопросу (это не означает, что он неинтересен, но просто не в нужном месте, ИМО, и я не вижу, где он может быть на самом деле, может прийти позже)
Тенсибай
Я попытаюсь еще раз уточнить - благодаря тому, что компакт-диск будет срезан настолько последовательно и быстро, мы сможем получить обратную связь от QA гораздо быстрее, чем раньше. Это уменьшило бункер. Это не устранило его, поскольку потребовалось еще год или два, прежде чем мы отключили вотчины вокруг централизованных бюджетов для деятельности, но это, безусловно, был критический шаг в макиге, который произошел. Мы также знали намного раньше, когда процесс выпуска был прерван. Я приписываю многим таким мелочам свой личный путь к DevOps.
Дэвид Бок
Этот последний комментарий придает больше смысла этому ответу по этому вопросу, вы должны отредактировать его, чтобы включить его, я все еще чувствую, что он не соответствует этому формату, но, похоже, моя позиция неверна, когда я наблюдаю общую эволюцию в этой частной бета-версии, поэтому ... это зависит от вас. Я не могу удалить свое понижение голосов без редактирования информации
Tensibai