Чат поддержки

Практикум
Привет! Это поддержка Практикума 👋 Если что-то не получается — постараемся помочь. Пишите в чат или выберите другой способ связи

пт, 2 декабряв 17:21

Мы уже начали заниматься вашим вопросом, ответим в ближайшее время

Практикум

Здравствуйте!

Поддержка не сможет помочь с вопросами, связанными с теорией или задачам из курса «Системный аналитик» — в этой ситуации рекомендуем вам обратиться к вашему преподавателю в чате в Slack.

Если же у вас возникнут иные вопросы — обязательно пишите, будем рады помочь :)

17:24

Выбрать способ связи

Перейти в профиль Практикума

Поменять когорту

Выйти из профиля

Добавить аккаунт

Дополнительные материалы

спринт Дополнительные материалы

Как учиться на курсе

4/4

К проекту 2

0/1

К спринту "Реализация системы"

2/2

Техника BDD

CI/CD

К спринту "Поддержка, обслуживание и оценка результатов"

1/1

SQL и системы визуализации

11/11

SQL и Python

7/10

Мягкие навыки аналитика. Коммуникация и активное слушание

4/4

Мягкие навыки аналитика. Постановка задач

5/5

Мягкие навыки аналитика. Планирование

4/4

Пригласить друзей

CI/CD

В этом уроке вы узнаете о методологии CI/CD, которая используется для автоматизации выпуска готового ПО.

Выпуск релизов ПО

Финальным этапом процесса разработки ПО является выпуск релиза. Релиз — это конечная стадия разработки ПО. На этом этапе ПО считается стабильным и, как правило, изменения в него не вносятся.

В каскадной (Waterfall) модели команды разработки часто выпускают ПО всего лишь один или пару раз за всё время выполнения проекта.

В гибкой (Agile) модели команды разработки стремятся как можно чаще выпускать работоспособное, готовое к использованию ПО. Одни команды выпускают релизы после выполнения нескольких итераций, другие — в конце каждой итерации или даже несколько раз за одну итерацию.

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

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

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

Не стоит забывать, что команда разработки должна выпускать релизы не только с той функциональностью, которая будет приносить пользу, но и в целом будет высокой по уровню качества. Чтобы достичь этих целей, то есть сократить время цикла разработки ПО и обеспечить высокое качество ПО, команде разработки следует:

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

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

Процесс автоматизированного выпуска релиза ПО

В общем виде процесс автоматизированного выпуска релиза ПО состоит из следующих основных этапов.

Стадия коммита (commit stage)
На этом этапе подтверждается, что система работает на техническом уровне. Программный код компилируется в двоичный файл, который затем проходит набор автоматизированных модульных тестов и статический анализ (static analysis), то есть анализ кода, осуществляемый без реального запуска ПО. Для статического анализа используют специальные программы, например, SonarQube, Collaborator и Checkmarx SAST.
Если тесты и статический анализ прошли успешно, то собирается установочный пакет.
Установочный пакет — это архив, содержащий файлы с кодом ПО и дополнительные метаданные, необходимые для их установки, обновления, настройки и удаления. Установочные пакеты могут иметь различный формат, который зависит от операционной системы устройства. Например, для Android используется формат APK, для MS Windows — MSI, для MacOS — PKG.

Автоматизированное приёмочное тестирование (automated acceptance testing stage)
На этом этапе подтверждается,что система работает на функциональном и нефункциональном уровне и что пользовательские требования выполнены.

Автоматизированное тестирование пропускной способности (automated capacity testing stage)
На этом этапе подтверждается, что система соответствует требованиям к пропускной способности.

Ручное тестирование (manual testing stage)
На этом этапе фокус смещается на поиск ошибок, которые не были обнаружены автоматизированными тестами.

Выпуск финальной версии ПО (release stage)
Передача системы пользователям. В зависимости от типа продукта и проекта передача происходит по-разному: публикация в AppStore, разворачивание в рабочей операционной среде, передача заказчику в виде виртуальных машин.

Последовательность этих этапов называется конвейером развёртывания (deployment pipeline). Конвейер развёртывания — это автоматизированный процесс сборки, развёртывания, тестирования и выпуска ПО.

Задачи конвейера развёртывания состоят в следующем:

он делает каждый этап процесса прозрачным для всех участников, способствуя совместной работе;

улучшает обратную связь, так что выявление и решение проблем происходит раньше по процессу;

позволяет командам развертывать и выпускать любую версию своего ПО в любую требуемую операционную среду путём полностью автоматизированного процесса.

На каком этапе автоматизированного выпуска релиза происходят следующие события.

Осуществляется автоматизированное тестирование

Автоматизированное приёмочное тестирование

На этапе автоматизированного приёмочного тестирования запускаются автоматизированные тесты, которые проверяют ПО на соответствие пользовательским требованиям

Передача системы пользователям

Выпуск финальной версии ПО

Выпуск финальной версии ПО означает, что система передается пользователям.

Сборка установочного пакета

Стадия коммита

Установочный пакет собирается на стадии коммита, если модульные тесты и статистический анализ кода пройдены успешно

Тестирование сложных неавтоматизированных сценариев

Ручное тестирование

На этом этапе тестировщики выполняют ручное тестирование.

Осуществляется нагрузочное тестирование

Автоматизированное тестирование пропускной способности

Для тестирования пропускной способности выполняется нагрузочное тестирование путем запуска автоматизированных тестов

Начать заново

Непрерывная интеграция, доставка и развёртывание

Одним из вариантов реализации конвейера развертывания на сегодняшний день является CI/CD — набор принципов и подходов к автоматизации процесса сборки, тестирования и развёртывания ПО.

CI/CD относится к гибкой (Agile) методологии, которая позволяет разработчикам сосредоточиться на реализации бизнес-требований, качестве кода и безопасности.

CI в названии означает непрерывную интеграцию (Continuous Integration, CI), а CD — непрерывную доставку (Continuous Delivery, CD).

Непрерывная интеграция

Непрерывная интеграция (CI) — это набор подходов (или практик), при которых в код вносятся небольшие изменения с частыми коммитами.

По сути CI — это попытка добиться того, чтобы установочный пакет в любой момент времени («непрерывно») содержал максимально актуальные (свежие) изменения, сделанные командой разработки.

Разработчики минимум один раз в день (некоторые чаще) коммитят свой код в репозиторий исходного кода. Сборка всего приложения осуществляется автоматически (по коммиту) или по расписанию, выполняется ряд автоматизированных тестов. Если процесс сборки или тестирования даёт сбой, команда разработчиков останавливает всё, что делали, и бросает все свои силы на устранение проблемы.

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

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

Непрерывная доставка

Непрерывная доставка (CD) — это набор подходов, позволяющих осуществлять автоматическое развёртывание ПО в целевую среду.

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

Теоретически при непрерывной доставке релизы можно планировать ежедневно, еженедельно, раз в две недели или в зависимости от требований ваших заказчиков. Однако если вы действительно хотите воспользоваться преимуществами непрерывной доставки, развёртывание в рабочей среде следует выполнять как можно раньше, чтобы быстрее устранять возникающие проблемы. Так появляется следующий уровень: непрерывное развёртывание.

Непрерывное развёртывание

Непрерывное развёртывание (Continuous deployment, CD) — это набор подходов, позволяющих полностью автоматизировать процесс развёртывания изменений, сделанных в коде, в рабочую среду.

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

Непрерывное развёртывание — отличный способ ускорить цикл обратной связи с вашими клиентами и снять нагрузку с команды, поскольку «дня релиза» больше нет. Разработчики видят, как их продукт приносит ценность через несколько минут после того, как они закончили работу над ним.

Например, Amazon утверждает, что, благодаря непрерывному развёртыванию, их рабочая среда изменяется каждые 11.6 секунд!

Определите о какой части CI/CD процесса идёт речь в следующих утверждениях:

Автоматизирование развёртывания приложений в различных операционных средах, начиная от среды разработчика и заканчивая рабочей.

Непрерывная доставка

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

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

Непрерывная интеграция

Сборка приложения после каждого изменения — задача непрерывной интеграции. Её цель состоит в том, чтобы программное обеспечение всё время находилось в рабочем состоянии.

Благодаря этой практике каждое изменение, прошедшее все этапы конвейера развёртывания, передаётся вашим клиентам.

Непрерывное развёртывание

Процесс передачи ПО клиентам — это непрерывное развёртывание. Оно идёт на шаг дальше, чем непрерывная доставка.

Начать заново

DevOps

CI/CD — это не только одна из гибких практик, но и практика DevOps.

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

Термин DevOps — это комбинация слов «разработка» (development) и «эксплуатация» (operations).

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

Системный аналитик обычно не взаимодействует с DevOps инженерами. Однако если такая роль не выделена отдельно, а выполняется разработчиками, системный аналитик может участвовать в обсуждении оптимизации процессов DevOps на уровне слушателя.

Подведём итоги

Релиз — это финальная стадия разработки ПО. На этом этапе ПО считается стабильным и, как правило, изменения в него не вносятся.

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

Автоматизация выпуска релизов позволяет сократить время цикла.

Процесс автоматизированного выпуска релиза ПО состоит из следующих основных этапов:

Стадия коммита (commit stage).

Автоматизированное приёмочное тестирование.

Автоматизированное тестирование пропускной способности.

Ручное тестирование.

Выпуск финальной версии ПО.

Последовательность этих этапов называется конвейером развёртывания. Одним из вариантов реализации конвейера развертывания является методология CI/CD.

Непрерванная интеграция (CI) — это набор подходов (или практик), при которых в код вносятся небольшие изменения с частыми коммитами.

Непрерывная доставка (CD) — это набор подходов, позволяющих осуществлять автоматическое развёртывание ПО в целевую среду.

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

К следующей теме
Краткий пересказ урока
beta

Курсы

Вводный модуль

Понимание профессии системного аналитика

Разработка требований

Проект 1. Спецификация требований ко второму релизу Chatty

SQL для аналитиков

Моделирование данных

Проект 2. Моделирование данных и работа с базой данных интернет-магазина «Накарабине»

Моделирование процессов

Пользовательские интерфейсы

Agile-практики

Проект 3. Бэклог приложения для сети клиник «Вита»

Трудоустройство

Архитектура системы

Программные интерфейсы

Проект 4

Реализация системы

Поддержка, обслуживание и оценка результатов

Дипломный проект

Дополнительные материалы

x