5. Plan > Code > Build > Testing > Release > Deploy > Operate > Monitor

Обновлено: 2024-03-12

4 мин

Содержание

Сегодня мы сосредоточимся на отдельных шагах от начала до конца и на непрерывном цикле приложения в мире DevOps.

DevOps

План

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

Code

Теперь, как только эта сессия планирования будет завершена, разработчики начинают писать код, в разработку котоого вы можете быть вовлечены, предоставляя информацю об инфрастуктуре, микросеврисах, если таковые имеются, и т.д. Когда разработчики заканчивают писать код/часть кода, они объединяют (merge) все измененияю и выгруат в репозиторий.

Build

Здесь мы начнем первый из наших процессов автоматизации, потому что мы “возьмем” их код и построим (скомпилируем, “сбилдим”) его в зависимости от того, какой язык они используют, это может быть транспиляция или компиляция, а может создать образ докера из этого кода в любом случае, мы собираемся пройти этот процесс, используя наш cicd pipeline (“пайплайн”)

Testing

После того, как мы его скомпилировали проект, мы проведем на нем несколько тестов. Команда разработчиков обычно пишет тесты. У вас может быть некоторый вклад в то, какие тесты пишутся, но нам нужно запустить эти тесты. Тестирование — это способ провериь и свести к минимуму появление проблем в рабочей среде. И хотя это не гарантирует полной проверки, но мы хотим максимально точно быть уверенными, что одна из новых функций не создает новых ошибок, а две другие не ломают то, что раньше работало.

Release

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

Deploy

Следующее, что мы собираемся сделать - это “деплой” (публикация/развертывание). Развертывание похоже на конечный результат процесса. Потому что после развертывания приложения, когда мы запускаем код в производство, наш бизнес действительно осознает ценность всех временных усилий и тяжелой работы, которые вы и команда разработчиков программного обеспечения вложили в этот продукт до этого момента.

Operate

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

Monitor

Все вышеперечисленные части ведут к последнему шагу - мониторингу, что важно особенно в отношении проблем, возникающих в рельном времени, автоматического масштабирования, устранения неполадок. Во время мониторига мы сохраняем данные об использовании памяти, использовании ЦП на диске, времени отклика, скорость отклика и т.д. Большая часть этого также является журналами. Журналы дают разработчикам возможность видеть, что происходит, без доступа к производственным системам.

Rince & Repeat

Once that’s in place you go right back to the beginning to the planning stage and go through the whole thing again

Continuous

Многие инструменты помогают нам достичь вышеуказанного непрерывного процесса, весь этот код и конечная цель полной автоматизации облачной инфраструктуры или любой среды часто описывается как непрерывная интеграция/непрерывная доставка/непрерывное развертывание или сокращенно «CI/CD». Позже, в течение 90 дней, мы посвятим целую неделю CI/CD с некоторыми примерами и пошаговыми руководствами, чтобы понять основы.

Continuous Delivery

Continuous Delivery = Plan > Code > Build > Test

Continuous Integration

Непрерывная интеграция - это результат описанных выше этапов непрерывной “доставки” и результат этапа выпуска. Это относится как к неудаче, так и к успеху, но это возвращается в непрерывную доставку или перемещается в непрерывное развертывание.

Continuous Integration = Plan > Code > Build > Test > Release

Continuous Deployment

Если у вас есть успешный релиз, перейдите к непрерывному развертыванию, которое включает следующие этапы.

Выпуск CI выполнен успешно = непрерывное развертывание = развертывание > эксплуатация > мониторинг

Вы можете рассматривать эти три понятия выше как простой набор фаз жизненного цикла DevOps.

Этот последний фрагмент был для меня чем-то вроде подведения итогов третьего дня, но думаю, что на самом деле это проясняет для меня ситуацию.

Источники

До встречи в День 6