Хочешь уверенно проходить IT-интервью?
Мы понимаем, как сложно подготовиться: стресс, алгоритмы, вопросы, от которых голова идёт кругом. Но с AI тренажёром всё гораздо проще.
💡 Почему Т1 тренажёр — это мастхэв?
- Получишь настоящую обратную связь: где затык, что подтянуть и как стать лучше
- Научишься не только решать задачи, но и объяснять своё решение так, чтобы интервьюер сказал: "Вау!".
- Освоишь все этапы собеседования, от вопросов по алгоритмам до диалога о твоих целях.
Зачем листать миллион туториалов? Просто зайди в Т1 тренажёр, потренируйся и уверенно удиви интервьюеров. Мы не обещаем лёгкой прогулки, но обещаем, что будешь готов!
Реклама. ООО «Смарт Гико», ИНН 7743264341. Erid 2VtzqwP8vqy
Чего хочет заказчик от отдела разработки?
Если раньше бизнес хотел от производства увеличения объема продукта или сервиса, то это решалось масштабированием ресурсов: больше сырья, больше рабочей силы и т. д.
Пришло время и рынок «насытился» товарами. Вектор стал смещаться на конкурентность за счет быстрой подстройки под запросы конечного потребителя. У бизнеса появилась потребность не только делать что-то новое, но и чаще вносить изменения в существующий код.
Частые изменения, например, для промышленного сектора, очень трудозатратны. Нельзя перенастраивать постоянно производственный автомобильный конвейер под меняющийся спрос на рынке.
Tesla, конечно, схитрила – сделала конвейер максимальной комплектации и зафиксировала софтом функционал, который приобретается в зависимости от потребности покупателя.
Для IT часто вносить изменения в продукт гораздо проще. Собственно, об этом и поговорим в статье.
Классический процесс разработки ПО
Классический процесс разработки ПО по принципу «часто и быстро» сложен в реализации. Передаем привет Каскадной модели разработки. На смену этой модели приходят Agile-методики, которые позволяют короткими спринтами накатывать изменения на минимальный прототип ПО.
Как раз организация CI\CD процесса и позволяет максимально быстро осуществлять большое количество изменений на каждом спринте.
Оптимизация процесса разработки ПО на частые релизы и изменения
Разберем подробнее:
- Continuous Integration (непрерывная интеграция). Базовая опция – это автоматические тесты кода вашего нового функционала и возможность автоматического отката (в случае плохих тестов) обратно.
- Continuous Deployment (непрерывное развертывание). Базовая опция – это развертывание кода нового функционала в тесте, а затем в продуктивном окружении.
Чтобы увидеть полную картину, взглянем на схему процесса CI\CD:
Для реализации необходимы следующие компоненты:
- Git – система контроля версий.
- Artifact Repository – система хранения артефактов сборки. По сути, это может быть общая файловая система, доступная всем участникам процесса.
- Deploy Server – ресурсы, на которых запускаются и тестируются изменения.
Теперь пройдемся по шагам процесса:
- Разработчик написал в коде реализацию нового изменения и добавил код в систему контроля версий Git.
- После добавления нового кода в Git код отправляется на сервер сборки.
- Автоматически, после сборки на сервере, стартуют тесты для проверки нового изменения. Результаты сохраняются в Artifact Repository.
- Артефакты отправляются в первый Deploy Server. Новый функционал развертывается в тестовой среде и опять же тестируется. Тестовая среда, в данном случае, – максимально идентичная к продуктивной среде, но без real-time пользователей.
- Артефакты отправляются во второй Deploy Server. Новый функционал развертывается уже в продуктивной среде, где находятся real-time пользователи. Это последний шаг в процессе доставки нашего изменения.
Что в итоге: большое количество тестов (автоматических тестов, без участия человека), две среды исполнения Non-Prod и Prod и общий Git.
Процесс CI\CD (его еще называют конвейер) позволяет:
- Исключить человеческий фактор на этапах тестирования, тем самым ускоряя его.
- Система контроля версий позволяет хранить в себе все изменения, т. е. исключается потеря информации и всегда можно откатиться обратно.
- Non-Prod и Prod среды позволяют отловить баги до того, как они попадут к real-time пользователям и нарушат функционал основного сервиса или приложения.
Данная статья первая в цикле из трех статей посвященных CI\CD. В следующий раз на практике рассмотрим реализацию Continuous Integration и Continuous Deployment.
Комментарии