v_sadist
@v_sadist
DevOps engineer

Как идет переход с «классики» на DevOPS?

Всем чмоки в этом чатике (с)

Коллеги, есть вопрос по переходу методологии нашей конторы на пресловутые DevOps

вводные:
Имеется софтверная контора, разработка идет по методологии Agile. Имеются все необходимые группы (QA, Release Management, ArchTeam, менеджеры проектов, продуктов и тд).
Регулярные релизы, автоматизированные, деплой обновления идет по расписанию, еженедельно брифинги по релизу (что можно выкатывать, что рано выкатывать и тд).
Инженерная группа (infrastructure) отвечает за сопровождение железа, сетей, ОС, СУБД, серверов приложений и прочие внутренности. Также мы отвечаем за автоматизированный деплой релиза.

Что может измениться при переходе с нашего принципа работы на пресловутый DevOps? Хотелось бы услышать тех, кто на DevOps перешел (и взлетел).
Также карма тому, кто посоветует годные материалы (как на русском, так и на англ) и литературу (кроме проекта феникс).
  • Вопрос задан
  • 1948 просмотров
Решения вопроса 1
Singaporian
@Singaporian
Нет никаких годных материалов. Точнее они годные только для опытных DevOps. Потому что это культура подхода, а не инструментарий.
Переход на DevOps делается в три этапа:
1) Сначала полностью все автоматизируется. По поводу доставки кода вопросы врядли возникнут - Jenkins и Maven известны даже детям. Ну не обязательно они. У каждого языка свои инструменты. gradle, grunt, waf... Но автоматиризровать надо все, включая деплой SQL (LiquidBase, dbMaintain, sqitch и т.д.). Эта часть освещена очень хорошо в интернетах.
2) Затем убираются все боттл-нэки в работе админов и программистов. Например внедряется Green/Blue-деплоймент. В точках деплоя собственного ПО средства провиженинга (puppet/ansible/chef) заменяются на средства деплоймента (uDeploy например). Устанавливается мониторинг и логирование. На все это тоже есть свои инструменты (Sensu например).
3) Начинается работа с людьми - вовлечение программистов в ответственность за результат на стороне Ops и вовлечение сисадминов(operations) в результат на стороне Dev (подгон под FHS и все такое). Ключевой момент в том, что людям придется понять, что их ответственность приходит эхом оттуда, где они своими руками не трогали (для этого даже автоматически создают новые энвайронменты всякими докерами и вагрантами). Закоммитил кривой код в IDE, не учел зависимость в пропертях, поправил конфиги не для всех энвайронментов - будешь отвечать и за статический анализ кода и за проваленные интеграционные тесты и за неудачный деплоймент. В обратную сторону тоже самое. Тогда люди начнут действовать по стандартам и настанет искомый результат.

Ну и само собой надо найти сильного релиз-инженера. Потому что DevOps - это не "построил и ушел". Кто-то должен все время смотреть за новыми организационными проблемами и чтобы транк не попал на UAT, например, а на SIT ушел тот же тэгированный код, которому на DEV провели smoke-тесты, а не обновленный парой вредных коммитов, набежавших за время смоука.

Сначала скажите, как звучит конечная задача и что из этого уже есть и чего нет. Может чего детальнее посоветую.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы