Андрей Трошин Телеграм @Andrey_Totshin Разбираемся, как разрабатывать ПО короткими спринтами с автоматическими тестами и развертыванием в продакшене. Чего хочет заказчик от отдела разработки? Если раньше бизнес хотел от производства увеличения объема продукта или сервиса, то это решалось масштабированием ресурсов: больше сырья, больше рабочей силы и т. д. Пришло время и рынок «насытился» товарами. Вектор стал смещаться на конкурентность за счет быстрой подстройки под запросы конечного потребителя. У бизнеса появилась потребность не только делать что-то новое, но и чаще вносить изменения в существующий код. Частые изменения, например, для промышленного сектора, очень трудозатратны. Нельзя перенастраивать постоянно производственный автомобильный конвейер под меняющийся спрос на рынке. Tesla, конечно, схитрила – сделала конвейер максимальной комплектации и зафиксировала софтом функционал, который приобретается в зависимости от потребности покупателя. Для IT часто вносить изменения в продукт гораздо проще. Собственно, об этом и поговорим в статье. Классический процесс разработки ПО Классический процесс разработки ПО по принципу «часто и быстро» сложен в реализации. Передаем привет Каскадной модели разработки. На смену этой модели приходят Agile-методики, которые позволяют короткими спринтами накатывать изменения на минимальный прототип ПО. Как раз организация CICD процесса и позволяет максимально быстро осуществлять большое количество изменений на каждом спринте. Оптимизация процесса разработки ПО на частые релизы и изменения Разберем подробнее: Continuous Integration (непрерывная интеграция). Базовая опция – это автоматические тесты кода вашего нового функционала и возможность автоматического отката (в случае плохих тестов) обратно. Continuous Deployment (непрерывное развертывание). Базовая опция – это развертывание кода нового функционала в тесте, а затем в продуктивном окружении. Чтобы увидеть полную картину, взглянем на схему процесса CICD: Схема процесса CICD Для реализации необходимы следующие компоненты: Git – система контроля версий. Artifact Repository – система хранения артефактов сборки. По сути, это может быть общая файловая система, доступная всем участникам процесса. Deploy Server – ресурсы, на которых запускаются и тестируются изменения. Теперь пройдемся по шагам процесса: Разработчик написал в коде реализацию нового изменения и добавил код в систему контроля версий Git. После добавления нового кода в Git код отправляется на сервер сборки. Автоматически, после сборки на сервере, стартуют тесты для проверки нового изменения. Результаты сохраняются в Artifact Repository. Артефакты отправляются в первый Deploy Server. Новый функционал развертывается в тестовой среде и опять же тестируется. Тестовая среда, в данном случае, – максимально идентичная к продуктивной среде, но без real-time пользователей. Артефакты отправляются во второй Deploy Server. Новый функционал развертывается уже в продуктивной среде, где находятся real-time пользователи. Это последний шаг в процессе доставки нашего изменения. Что в итоге: большое количество тестов (автоматических тестов, без участия человека), две среды исполнения Non-Prod и Prod и общий Git. Процесс CICD (его еще называют конвейер) позволяет: Исключить человеческий фактор на этапах тестирования, тем самым ускоряя его. Система контроля версий позволяет хранить в себе все изменения, т. е. исключается потеря информации и всегда можно откатиться обратно. Non-Prod и Prod среды позволяют отловить баги до того, как они попадут к real-time пользователям и нарушат функционал основного сервиса или приложения. Данная статья первая в цикле из трех статей посвященных CICD. В следующий раз на практике рассмотрим реализацию Continuous Integration и Continuous Deployment. Материалы по теме ТОП-10 актуальных книг по DevOps: от новичка до профессионала Современный подход к кибербезопасности: как внедрить в компании методики DevSecOps? Путь в профессию: интервью с инженером DevOps
Телеграм @Andrey_Totshin Разбираемся, как разрабатывать ПО короткими спринтами с автоматическими тестами и развертыванием в продакшене. Чего хочет заказчик от отдела разработки? Если раньше бизнес хотел от производства увеличения объема продукта или сервиса, то это решалось масштабированием ресурсов: больше сырья, больше рабочей силы и т. д. Пришло время и рынок «насытился» товарами. Вектор стал смещаться на конкурентность за счет быстрой подстройки под запросы конечного потребителя. У бизнеса появилась потребность не только делать что-то новое, но и чаще вносить изменения в существующий код. Частые изменения, например, для промышленного сектора, очень трудозатратны. Нельзя перенастраивать постоянно производственный автомобильный конвейер под меняющийся спрос на рынке. Tesla, конечно, схитрила – сделала конвейер максимальной комплектации и зафиксировала софтом функционал, который приобретается в зависимости от потребности покупателя. Для IT часто вносить изменения в продукт гораздо проще. Собственно, об этом и поговорим в статье. Классический процесс разработки ПО Классический процесс разработки ПО по принципу «часто и быстро» сложен в реализации. Передаем привет Каскадной модели разработки. На смену этой модели приходят Agile-методики, которые позволяют короткими спринтами накатывать изменения на минимальный прототип ПО. Как раз организация CICD процесса и позволяет максимально быстро осуществлять большое количество изменений на каждом спринте. Оптимизация процесса разработки ПО на частые релизы и изменения Разберем подробнее: Continuous Integration (непрерывная интеграция). Базовая опция – это автоматические тесты кода вашего нового функционала и возможность автоматического отката (в случае плохих тестов) обратно. Continuous Deployment (непрерывное развертывание). Базовая опция – это развертывание кода нового функционала в тесте, а затем в продуктивном окружении. Чтобы увидеть полную картину, взглянем на схему процесса CICD: Схема процесса CICD Для реализации необходимы следующие компоненты: Git – система контроля версий. Artifact Repository – система хранения артефактов сборки. По сути, это может быть общая файловая система, доступная всем участникам процесса. Deploy Server – ресурсы, на которых запускаются и тестируются изменения. Теперь пройдемся по шагам процесса: Разработчик написал в коде реализацию нового изменения и добавил код в систему контроля версий Git. После добавления нового кода в Git код отправляется на сервер сборки. Автоматически, после сборки на сервере, стартуют тесты для проверки нового изменения. Результаты сохраняются в Artifact Repository. Артефакты отправляются в первый Deploy Server. Новый функционал развертывается в тестовой среде и опять же тестируется. Тестовая среда, в данном случае, – максимально идентичная к продуктивной среде, но без real-time пользователей. Артефакты отправляются во второй Deploy Server. Новый функционал развертывается уже в продуктивной среде, где находятся real-time пользователи. Это последний шаг в процессе доставки нашего изменения. Что в итоге: большое количество тестов (автоматических тестов, без участия человека), две среды исполнения Non-Prod и Prod и общий Git. Процесс CICD (его еще называют конвейер) позволяет: Исключить человеческий фактор на этапах тестирования, тем самым ускоряя его. Система контроля версий позволяет хранить в себе все изменения, т. е. исключается потеря информации и всегда можно откатиться обратно. Non-Prod и Prod среды позволяют отловить баги до того, как они попадут к real-time пользователям и нарушат функционал основного сервиса или приложения. Данная статья первая в цикле из трех статей посвященных CICD. В следующий раз на практике рассмотрим реализацию Continuous Integration и Continuous Deployment. Материалы по теме ТОП-10 актуальных книг по DevOps: от новичка до профессионала Современный подход к кибербезопасности: как внедрить в компании методики DevSecOps? Путь в профессию: интервью с инженером DevOps
Если раньше бизнес хотел от производства увеличения объема продукта или сервиса, то это решалось масштабированием ресурсов: больше сырья, больше рабочей силы и т. д.
Пришло время и рынок «насытился» товарами. Вектор стал смещаться на конкурентность за счет быстрой подстройки под запросы конечного потребителя. У бизнеса появилась потребность не только делать что-то новое, но и чаще вносить изменения в существующий код.
Частые изменения, например, для промышленного сектора, очень трудозатратны. Нельзя перенастраивать постоянно производственный автомобильный конвейер под меняющийся спрос на рынке.
Tesla, конечно, схитрила – сделала конвейер максимальной комплектации и зафиксировала софтом функционал, который приобретается в зависимости от потребности покупателя.
Для IT часто вносить изменения в продукт гораздо проще. Собственно, об этом и поговорим в статье.
Классический процесс разработки ПО по принципу «часто и быстро» сложен в реализации. Передаем привет Каскадной модели разработки. На смену этой модели приходят Agile-методики, которые позволяют короткими спринтами накатывать изменения на минимальный прототип ПО.
Как раз организация CICD процесса и позволяет максимально быстро осуществлять большое количество изменений на каждом спринте.
Разберем подробнее:
Чтобы увидеть полную картину, взглянем на схему процесса CICD:
Схема процесса CICD
Для реализации необходимы следующие компоненты:
Теперь пройдемся по шагам процесса:
Что в итоге: большое количество тестов (автоматических тестов, без участия человека), две среды исполнения Non-Prod и Prod и общий Git.
Процесс CICD (его еще называют конвейер) позволяет:
Данная статья первая в цикле из трех статей посвященных CICD. В следующий раз на практике рассмотрим реализацию Continuous Integration и Continuous Deployment.
Ваш адрес email не будет опубликован. Обязательные поля помечены *
Сохранить моё имя, email и адрес сайта в этом браузере для последующих моих комментариев.
Δ
Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.