Данная работа является последней проверочной работой в этом году. Она будет защищаться на экзамене.

Программные средства поддержки разработки ПО

В настоящий момент можно выделить следующие стандартные средства по поддержке процесса разработки:

  • трекеры задач;
  • репозиторий систем контроля версий;
  • система непрерывной интеграции изменений.

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

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

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

Признаком хорошей интеграции систем является возможность изменения состояния в одной системе по результатам действия в другой. К таким действиям можно отнести:

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

Ваша задача продемонстрировать не только установку данных систем с помощью Docker, но и их успешную интеграцию друг с другом.

Общее описание задачи

Вам необходимо создать среду для поддержки процесса разработки ПО в небольшой компании. Среда технически должна функционировать на Docker-технологиях.

Принципиальный подход к развёртыванию финальной версии системы:

  1. Установить на компьютер Docker и Docker Compose.
  2. Скопировать на компьютер (склонироварь репозиторий) разработанную конфигурацию.
  3. Отредактировать конфигурационные файлы, указав там параметры развёртывания:
    • секретные ключи;
    • название домена для работы системы.
  4. Запустить конфигурацию с помощью Docker Compose.

После этого все службы поддержки разработки ПО должны быть запущены.

Необходимо также разработать процесс резервного копирования данных системы. Он должен быть максимально автоматизирован, т.е. для создания резервной копии для всей конфигурации пользователю необходимо выполнить только одно действие. Данный скрипт может быть написан на Ruby.

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

  1. Описана общая структура конфигурации Docker Compose и назначение отдельных её элементов.
  2. Для каждой службы должно быть приведено описание Dockerfile, который был использован для создания контейнера, если вы формировали его самостоятельно.
  3. Если настройку развёртывания необходимо проводить за пределами конфигурации Docker Compose, тогда надо также предоставить эту информацию. Также необходимо обосновать использование внешних по отношению к Docker Copmose средств настройки среды.
  4. Пример настройки проекта, включающего в себя:
    • Создание проекта в системе управления задачамиу.
    • Создание репозитория в системе управления репозиториями.
    • Создание задач проверки исходного кода в системе непрерывной интеграции.
    • Связывание систем друг с другом для выполнения автоматических действий.
  5. Руководство по использованию инструмента для создания резервных копий.
  6. Руководство по восстановлению состояния системы из резервной копии.

Варианты средств поддержки разработки ПО

Системы управления задачами

Системы управления репозиториями

Системы непрерывной интеграции:

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

Вы можете предложить альтернативные системы для каждого из разделов, но они должны быть одобрены преподавателем.

Технические требования к реализации

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

  • В корне должен располагаться файл docker-compose.yml, с помощью которого необходимо осуществлять настройку системы.
  • Для каждого используемого средства необходимо создать каталог. В каждом из каталогов должны быть
    • Dockerfile для формирования образа данного средства.
    • Дополнительные файлы, которые нужны для формирования образа средства.
    • Эти каталоги не должны содержать конфигурации, связанной с развёртыванием, а только со сборкой образа.
  • В корне проекта должен располагаться каталог doc, содержащий документацию о проекте.
  • В корне проекта должен располагаться каталог backup, содержащий скрипты для создания резервных копий.
  • В корне проекта может располагаться каталог config, в котором могут располагаться файлы конфигурации, связанные с конкретным развёртыванием системы.

Dockerfile могут быть написаны вами или взяты с hub.docker.com. В любом случае их структура должна быть задокументирована.

Порядок проведения защиты

  1. Каждому студенту предоставляется доступ к виртуальной машине.
  2. За 2 часа необходимо выполнить развёртывание разработанной конфигурации и подготовиться к презентации. Для развёртывания следует использовать конфигурации, присланные на Moodle.
  3. По истечении этого времени или по готовности студенту необходимо провести демонстрацию своего решения. Она должна включать в себя:
    1. Описание конфигурации Docker Compose с кратким рассказом о структуре Docker-файлов.
    2. Демонстрацию работы каждого из проектов.
    3. Демонстрацию по настройке связи между проектами.
    4. Демонстрацию работы скриптов по созданию резервных копий важных данных.

    Демонстрация должна быть рассчитана на 10 минут.

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