Конфигурационное управление

Начать. Это бесплатно
или регистрация c помощью Вашего email-адреса
Конфигурационное управление создатель Mind Map: Конфигурационное управление

1. Управление сборками

1.1. Процедуру сборки проекта часто автоматизируют, то есть выполняют не из среды разработки, а из специального скрипта – build-скрипта.

1.1.1. Этот скрипт используется тогда, когда разработчику требуется полная сборка всего проекта. А также он используется в процедуре непрерывной интеграции (continues integration) – то есть регулярной сборке всего проекта (как правило – каждую ночь).

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

2. Управление версиями файлов

2.1. Управление версиями файлов

2.1.1. Одновременно может существовать несколько версий системы

2.1.2. И в том и в другом случае в средстве управления версиями образуются разные ветки.

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

3. У каждой единицы конфигурационного управления должно быть следующее.

3.1. Структура – набор файлов. Например, пользовательская документация в html должна включать индекс-файл и набор html-файлов, а также набор вынесенных картинок (gif или jpeg-файлы).

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

3.3. Практика конфигурационного управления – кто и в каком режиме, а также в какое место выкладывает новую версию элемента конфигурационного управления.

3.4. Автоматическая процедура контроля целостности элемента – например, сборка для исходных текстов программ.

4. Рассмотрим проект по разработке программного обеспечения. Что в нем является аналогом материальных активов на обычном производстве?

4.1. Учет и контроль, сродни складскому, требуют файлы проекта. В программном проекте их очень много – сотни и тысячи даже для относительно небольших проектов. Многие технологии программирования поддерживают стиль, когда, например, для каждого класса создается свой отдельный файл.

4.1.1. Файл – это виртуальная информационная единица.

4.1.2. Отличие файла от учета материальных единиц: - В том, что у файла может быть версия, и не одна, и породить эти версии очень легко – достаточно скопировать данный файл в другое место на диске. - В то время как материальные предметы существуют на складе сами по себе, и для них нет понятия версии.

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

6. Две основные задачи в конфигурационном управлении

6.1. управление версиями

6.1.1. отвечает за управление версиями файлов и выполняется в проекте на основе специальных программных пакетов – средств версионного контроля.

6.2. управление сборками

6.2.1. Управление сборками – это автоматизированный процесс трансформации исходных текстов ПО в пакет исполняемых модулей, учитывающий многочисленные настройки проекта, настройки компиляции, и интегрируемый с процессом автоматического тестирования.

6.2.1.1. Эта процедура является мощным средством интеграции проекта, основой итеративной разработки.

7. Конфигурационное управление имеет дело с меняющимися в процессе продуктами, состоящими из наборов файлов. Такие продукты принято называть единицами конфигурационного управления.

7.1. Примеры: 1. пользовательская документация; 2. проектная документация; 3. исходные тексты ПО; 4. пакеты тестов; 5. инсталляционные пакеты ПО; 6. тестовые отчеты.

8. Понятие baseline

8.1. Baseline – это базовая, последняя целостная версия некоторого продукта разработки, например, документации, программного кода и т.д.

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

8.3. Baseline может также поддерживаться непрерывной интеграцией.

8.4. Baseline (особенно в случае с программными активами) не должна устанавливаться слишком рано. Сначала нужно написать какое-то количество кода, чтобы было что интегрировать.