Предпосылки для версионированияПО. Ветвление

Основные предпосылки:

- повышение надёжности хранения артефактов;

- общий доступ к файлам- предполагается одновременное редактирование одного файла разными пользователями, что может привести к потере изменений сделанных пользователем (затёрты записью изменений другого пользователя);

- сохранение истории модификации файла - необходимо иметь историю изменения файла. Вводится понятие версия файла, которая включает автора изменений, время, суть, причину изменений и т.д.;

- возможность возврата к предыдущим версиям файла;

- пометка отдельных версий файла. Причины пометки: качественная версия; версия, обладающая определёнными свойствами; версия, являющаяся частью релиза проекта определённой версии.

- поддержание и развитие нескольких параллельных историй файла (ветвление).

Причины ветвления:

- развитие нескольких версий проекта (поставленных заказчику, разрабатываемых);

- наличие нескольких конфигураций проекта (для разной аппаратуры, для разных ОС).

1. Одной из причин ветвления версий ПО является:

2. Причина пометки версии файла:

Системы контроля версий. Типы СКВ. Основные принципы организации

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

Типы СКВ:

- централизованная СКВ: единое централизованное хранилище, клиент-серверный доступ;

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

Общие принципы организации.

У каждой версии файла существует уникальный идентификатор - ревизия. При изменении файла номер ревизии увеличивается по определённому правилу. Иногда номер ревизии является атрибутом всего репозитория.

Копии проекта:

- для централизованных СКВ: локальная копия проекта; локальная копия проекта, находящегося под контролем СКВ; серверная копия, находящаяся в репозитории;

- для распределённых СКВ:локальная копия проекта; локальная копия проекта, находящегося под контролем СКВ; копия, находящаяся в локальном репозитории; копия, находящаяся в удалённом репозитории.

Поддержка текстового (инкрементные изменения, возможность визуального сравнения ревизий) и бинарного (хранение всех версий) форматов хранения.

Тэг - текстовая метка, привязанная к ревизии файла или репозитория. Ревизия может содержать несколько тэгов. Выборку ревизии файла можно производить по тэгам.

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

1. Уникальным идентификатором версии файла является:

2. Наличие удалённого репозитория характерно для:

Системы контроля версий. Типовые операции

Импорт проекта - первоначальное помещение локального проекта в репозиторий СКВ;

Экспорт проекта - извлечение проекта из СКВ в локальный каталог, удаление проекта из СКВ;

Получение проекта - получение локального слепка проекта (по различным критериям, например, по тэгу);

Обновление файла - копирование свежих версий из репозитория, слияние локальных изменений и серверных в локальном файле;

Фиксация изменений - посылка изменённой версии файла в репозиторий; операция игнорируется, если ревизия на сервере изменилась;

Сравнение изменений- сравнивать можно любые две ревизии одного файла из любых ветвей (работает только для текстовых файлов);

Установка тэгов;

Переход к другой ревизии (откат);

Создание ветвей- ветвь -это механизм группирования, который служит для ветвления дерева ревизий файла;

Переключение на ветвь- происходит с помощью имени ветви;

Слияние;

Разрешение конфликтов- если при слиянии произошёл конфликт (одна строка кода изменена по-разному в двух версиях), то в текст попадают обе версии участков кода с пометками; разрешение производится только в локальной копии; в репозитории хранится только утверждённая версия с разрешёнными конфликтами;

Блокировка;

Синхронизация репозиториев (для РСКВ);

1. Извлечение проекта из СКВ в локальный каталог это:

2. Механизм группирования, который служит для ветвления дерева ревизий файла это:

Сборка программных проектов. Проблемы при сборке программных проектов

Сборка - набор правил и процедур, направленный на получение исполняемой программы.

Задачи сборки: трансляция всего проекта; сборка дистрибутива; подготовка исходных текстов; подготовка документации.

Причины сборки: проверка работоспособности; очередная периодическая сборка (обычно еженощно); подготовка версии к автоматическому тестированию; подготовка дистрибутива; инсталляция дистрибутива.

Проблемы при сборке:

- с исходными файлами: отсутствуют, некорректное расположение, некорректные версии;

- с подключаемыми файлами: отсутствуют, некорректное расположение, некорректные версии;

- с используемыми библиотеками: отсутствуют, некорректное расположение, некорректные версии;

- с процедурами сборки: отсутствуют процедуры сборки или компонентов сборки проекта, некорректные версии;

- со средствами сборки: неполный состав средств сборки, некорректные версии средств;

- проблемы с системной средой и аппаратной платформой сборки: неправильная версия ОС или компонентов ОС, некорректный состав аппаратуры (тип процессора, количество ядер), некорректные параметры аппаратуры (скорость процессора, объём памяти и т.д).

1. Набор правил и процедур, направленный на получение исполняемой программы:

Сборка программных проектов. Окружение для сборки. Общие требование к системе сборки. Версии в программных проектах

Окружение: аппаратная платформа (ПК); системное окружение (ОС, системные файлы); библиотечное окружение (подключаемые и библиотечные файлы); исходные файлы в требуемых каталогах; средства сборки.

Общие требования.

- сборка должна проводиться на любом ПК с подготовленным окружением;

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

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

1. К окружения для сборки относятся:

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

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

Действия в системах НИ:

- инкремент текущего номера сборки;

- пометка текущим тэгом сборки файлов собираемого проекта;

- получение проекта, помеченного тэгом, из репозитория;

- сборка проекта: по расписанию (обычно ночью, полная процедура сборки), по каждому обновлению файлов репозитория (с целью проверки определения того, что данное обновление не испортило систему, процедура сборки сокращённая, длительность 5-15 минут), или по запросу;

- запуск тестирования (и других процедур обеспечения качества);

- развёртывание проекта;

- формирование отчёта.

1. Сборка по каждому обновлению файлов репозитория предполагает: