0201

1.

Виды и средства контроля
разработки проекта ПО.
Управление версиями.
Локальные системы контроля
версий. Централизованные
системы контроля версий.
Распределенные системы
контроля версий
Евграфова З.

2.

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

3.

Виды контроля в процессе разработки ПО
Контроль требований и
спецификаций
Контроль качества кода
Этот вид контроля гарантирует, что разрабатываемое
программное обеспечение точно соответствует
изначальным бизнес-требованиям и функциональным
спецификациям. Он включает в себя регулярные
проверки, чтобы убедиться, что продукт движется в
правильном направлении и удовлетворяет ожиданиям
заказчика.
Охватывает статический анализ кода, рецензирование
(Code Review) и тестирование. Статический анализ
помогает выявить потенциальные проблемы
безопасности и стиля кодирования до запуска. Ревью
позволяет другим разработчикам проверить логику и
читаемость кода, а тестирование (модульное,
интеграционное, системное) подтверждает его
работоспособность и отсутствие дефектов.
Контроль конфигураций
Контроль изменений
Управление различными версиями компонентов,
библиотек и настроек, используемых в проекте. Это
критически важно для обеспечения
воспроизводимости сборок и развертываний, а также
для избежания "ада зависимостей", когда разные
версии компонентов конфликтуют друг с другом.
Систематический процесс отслеживания, оценки и
согласования всех предложенных изменений в
проекте. Это помогает управлять эволюцией продукта,
предотвращая несанкционированные или
нежелательные модификации, которые могут
нарушить стабильность или функциональность.

4.

Что такое управление версиями?
Система управления версиями (VCS) — это программное
обеспечение, предназначенное для хранения и
отслеживания изменений в файлах, особенно в исходном
коде, документации и других активах проекта. Это
незаменимый инструмент в современном процессе
разработки ПО, который позволяет командам работать
эффективно и избегать распространенных проблем,
связанных с параллельной разработкой.
VCS не только сохраняет полную историю всех
модификаций, но и предоставляет возможность легко
возвращаться к любой предыдущей версии проекта. Это
критически важно для отладки, исправления ошибок и
анализа того, как развивался проект с течением времени.
Без VCS совместная работа нескольких разработчиков над
одним и тем же набором файлов была бы крайне
затруднительной и чреватой потерей данных или
перезаписыванием чужих изменений.

5.

Модели систем управления версиями
Централизованная модель
Распределённая модель
В этой модели существует единый центральный сервер,
который хранит весь репозиторий проекта. Разработчики
"выгружают" (checkout) файлы с сервера, вносят
изменения, а затем "фиксируют" (commit) их обратно на
сервер. Это обеспечивает простой и понятный контроль за
тем, кто и что меняет.
В распределенной модели каждый разработчик имеет
полную копию всего репозитория проекта, включая всю
его историю. Это означает, что разработчики могут
работать офлайн, фиксировать изменения в своих
локальных репозиториях, а затем синхронизировать их с
другими репозиториями (например, с "удаленным"
центральным репозиторием).
Примеры таких систем включают SVN (Subversion) и
Perforce. Основные преимущества — простота настройки
и управления, а также единая точка истины для всех
изменений. Однако есть и недостатки: центральный
сервер является единственной точкой отказа, и
отсутствие доступа к нему блокирует работу всей
команды. Кроме того, история изменений доступна
только при подключении к серверу.
Примеры распределенных систем включают Mercurial.
Главные преимущества — устойчивость к отказам
(поскольку каждая копия является полным бэкапом),
гибкость в рабочих процессах и возможность более
сложного ветвления и слияния. Недостатки могут
включать более сложную начальную настройку и
потенциально больший объем данных на локальных
машинах.

6.

Ключевые функции систем управления
версиями
Отслеживание изменений
Разрешение конфликтов
VCS ведет детальный журнал всех изменений: кто, когда,
что именно изменил. Это позволяет получить полную
картину эволюции проекта и быстро определить
источник любой проблемы.
Когда несколько разработчиков изменяют одну и ту же
часть файла, VCS помогает автоматически или
полуавтоматически обнаруживать и разрешать
конфликты, предоставляя инструменты для ручного
объединения изменений.
Откат к стабильным версиям
Хранение изменений в виде дельт
При обнаружении критической ошибки или
нежелательного изменения, VCS позволяет мгновенно
откатить проект к любой предыдущей стабильной
версии, минимизируя время простоя и потери.
Для экономии дискового пространства большинство VCS
хранят не полные копии файлов при каждом изменении, а
только "дельты" — различия между последовательными
версиями. Это обеспечивает эффективное использование
ресурсов.
Эти функции делают системы управления версиями краеугольным камнем современной разработки, обеспечивая
надежность, эффективность и возможность совместной работы над сложными проектами.

7.

Принципы эффективного управления
версиями
Чёткая нумерация версий
Регулярные коммиты
Использование стандартов, таких как семантическое
версионирование (MAJOR.MINOR.PATCH), помогает
команде и пользователям понимать характер изменений
в каждой новой версии. Это позволяет легко отличать
релизы с новыми функциями от исправлений ошибок.
Частые и небольшие коммиты с информативными
сообщениями делают историю проекта более читаемой и
облегчают отслеживание изменений. Каждое сообщение
коммита должно четко описывать, что было сделано и
почему.
Использование ветвления
Документирование изменений
Ветвление (branching) позволяет разработчикам работать
над новыми функциями или исправлениями ошибок
изолированно от основной кодовой базы. Это
предотвращает внесение нестабильных изменений в
основной проект и способствует параллельной разработке.
Подробное документирование изменений, включая
причины их внесения, является ключевым для
поддержания прозрачности проекта. Это помогает новым
членам команды быстрее разобраться в проекте и
облегчает долгосрочное сопровождение.

8.

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

9.

Практические советы по контролю разработки
и версиям
Внедряйте контроль версий с самого начала
Обучайте команду работе с VCS
Не ждите, пока проект разрастется. Интегрируйте
систему управления версиями с первого дня, чтобы
сохранить полную историю изменений и избежать
проблем в будущем.
Проведите обучение для всех членов команды по
правильному использованию системы управления
версиями, включая ветвление, слияние и разрешение
конфликтов. Дисциплина — залог успеха.
Используйте инструменты для
автоматизации
Регулярно проводите ревью и аудит
Автоматизируйте тестирование, сборку и развертывание
с помощью систем непрерывной
интеграции/непрерывной доставки (CI/CD). Это поможет
обнаруживать проблемы на ранних этапах и обеспечивать
стабильность.
Практикуйте регулярные код-ревью для улучшения
качества кода. Периодически проводите аудит изменений
в системе контроля версий для выявления
потенциальных проблем и обеспечения соответствия
стандартам.

10.

Локальные системы
контроля версий

11.

Что такое система контроля версий?
Фиксация изменений
Сохранение истории
Локальное хранение
Система, фиксирующая изменения
файлов с течением времени и
позволяющая вернуться к любой
предыдущей версии. Это
обеспечивает полный контроль над
эволюцией проекта.
Обеспечивает сохранность всей
истории проекта, что критически
важно для отслеживания ошибок,
анализа развития и возврата к
стабильным состояниям. Упрощает
работу с изменениями, делая её
прозрачной и контролируемой.
Локальные системы контроля версий
хранят все данные и историю
изменений непосредственно на одном
компьютере пользователя. Это
означает независимость от сетевого
подключения для базовых операций.

12.

Локальные системы контроля версий:
принцип работы
Принцип работы локальных систем контроля версий
основан на хранении истории изменений в виде
последовательности патчей или снимков состояния
файлов. Это позволяет эффективно управлять
пространством и быстро восстанавливать нужные версии.
История изменений хранится на локальном диске
пользователя.
Для каждой новой версии фиксируются только
изменения (патчи) или полный снимок состояния
файлов.
Пример: RCS (Revision Control System) — одна из первых
и наиболее известных локальных систем, которая
использовала патчи для эффективного управления
версиями файлов.
Возможность мгновенного отката к любой предыдущей
версии без необходимости подключения к сети.

13.

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

14.

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

15.

Исторический пример: система RCS
Revision Control System (RCS) — это одна из первых
систем контроля версий, разработанная в 1982 году
Уолтером Ф. Тихом. Она стала основой для многих
последующих разработок в области управления версиями.
Разработана для операционных систем UNIX и быстро
получила широкое распространение.
Основной принцип работы RCS — хранение только
различий (патчей) между версиями файла, что
позволяло экономить дисковое пространство.
Несмотря на свою локальную природу и отсутствие
сетевых возможностей, RCS предлагала эффективный
способ управления отдельными файлами и их версиями.
Позволяла создавать и управлять различными ветками
разработки одного файла.
RCS оказала значительное влияние на развитие других систем контроля версий, заложив фундаментальные идеи.

16.

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

17.

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

18.

Типы систем контроля
версий
Локальные СКВ
Все версии файлов и их история
Централизованные
СКВ (ЦСКВ)
хранятся на одном компьютере
Единый сервер содержит полную
пользователя. Просты, но не подходят
историю версий, а клиентские
для командной работы.
машины получают только рабочие
копии.
Распределённые СКВ (РСКВ)
Каждый разработчик имеет полную копию репозитория со всей историей. Серверы
используются для синхронизации, но не являются единственным источником
истины.

19.

Архитектура централизованных систем
контроля версий
Централизованные системы контроля версий строятся вокруг идеи единого, надёжного хранилища.
В основе ЦСКВ лежит единый сервер, который выступает в роли
«источника правды» для всего проекта. Все изменения, вся история
версий хранятся на этом сервере в центральном репозитории.
Разработчики используют клиентское программное обеспечение для
взаимодействия с сервером. Они получают (check-out) рабочие копии
файлов, вносят в них необходимые изменения и затем отправляют
(check-in) эти изменения обратно на сервер.
Примеры таких систем включают CVS, Apache Subversion (SVN) и
Perforce, которые долгое время были стандартами в индустрии.

20.

Преимущества централизованных систем
Единый контроль доступа
Простота администрирования
Легко управлять правами доступа пользователей к
различным частям проекта, обеспечивая высокий
уровень безопасности и конфиденциальности.
Управление системой осуществляется на одном
сервере, что упрощает настройку, обслуживание и
мониторинг.
Централизованное хранение
Поддержка ветвления и слияния
Все изменения и история проекта хранятся в одном
месте, что значительно облегчает создание резервных
копий и проведение аудита.
ЦСКВ позволяют создавать ветви (branches) для
параллельной разработки и объединять (merge)
изменения обратно в основную ветку, хотя процесс
может быть сложнее, чем в РСКВ.

21.

Ограничения и риски
централизованных систем
Единая точка отказа
Если центральный сервер выходит из строя или становится недоступным, вся командная работа останавливается, так
как нет доступа к репозиторию.
Зависимость от сети
Для каждой операции (получение, отправка изменений) требуется активное сетевое соединение с сервером. Медленное
или нестабильное соединение сильно замедляет работу.
Риск потери данных
В случае сбоя сервера без актуальных резервных копий, существует риск полной потери истории проекта.
Конфликты и задержки
Параллельная работа больших команд может приводить к частым конфликтам при слиянии изменений, требуя ручного
разрешения и замедляя процесс разработки.

22.

Исторический пример: CVS — пионер централизованных
систем
CVS (Concurrent Versions System) сыграла ключевую роль в становлении контроля версий и
стала фундаментом для последующих систем.
Выпущенная в 1990 году, CVS быстро завоевала
популярность, особенно в сообществе разработчиков
открытого ПО и Unix. Она стала одной из первых широко
используемых систем, позволяющих нескольким
разработчикам одновременно работать над одним
проектом, отслеживая и объединяя их изменения.
Её клиент-серверная архитектура обеспечивала
централизованное хранение и управление версиями
исходного кода, что было революционным для того
времени.
Пик её популярности пришелся на 1990-е и начало 2000х годов. Однако к 2008 году её развитие практически
остановилось, и сегодня она считается устаревшей, уступив
место более современным и гибким решениям.

23.

Современный контекст и
переход к распределённым
системам
Ландшафт систем контроля версий значительно изменился за последние десятилетия.
Снижение доминирования
Централизованные системы, такие как SVN, по-прежнему используются, но
их доля на рынке значительно сократилась по сравнению с
распределёнными системами.
Рост РСКВ
Инструменты вроде Git и Mercurial стали доминирующими благодаря своей
отказоустойчивости, высокой скорости работы, особенно в офлайн-режиме,
и более гибким моделям ветвления.
Нишевые применения ЦСКВ
Тем не менее, централизованные системы сохраняют актуальность для
некоторых корпоративных задач, где строгий централизованный контроль
доступа и простота аудита остаются критически важными.
Гибридные подходы
Многие проекты используют гибридные подходы, комбинируя
преимущества обеих архитектур, например, централизованные репозитории
Git-хостинга.

24.

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

25.

Что такое система контроля
версий (СКВ)?
Отслеживание изменений
Совместная работа
СКВ — это программный
инструмент, который
записывает все изменения,
внесённые в файлы проекта с
течением времени. Это
позволяет разработчикам легко
просматривать историю
версий, определять, кто и когда
вносил изменения, а также
возвращаться к любой
предыдущей версии файла или
всего проекта.
СКВ критически важны для
командной разработки. Они
обеспечивают координированное
взаимодействие нескольких
разработчиков над одним
проектом, предотвращая
перезаписывание чужих
изменений и упрощая
объединение работы. Это
минимизирует конфликты и
значительно повышает
производительность команды.
Предотвращение потери данных
Благодаря тщательному отслеживанию всех изменений, СКВ
являются мощным средством защиты от случайной потери данных.
Если возникает ошибка или нежелательное изменение, всегда
можно восстановить рабочую версию проекта, что обеспечивает
безопасность и стабильность разработки.

26.

Эволюция СКВ: от локальных к
централизованным системам
Локальные СКВ (1970-е)
Вызовы централизованных систем
Начало использования СКВ связано с простыми
инструментами, такими как RCS (Revision Control
System) и SCCS (Source Code Control System). Они
хранили историю изменений непосредственно на
компьютере разработчика, что делало совместную
работу громоздкой и склонной к ошибкам.
Несмотря на свои преимущества, CVCS сталкивались с
проблемами: высокая зависимость от доступности
сервера, узкие места в производительности и сложности
при работе в условиях ограниченного доступа к сети. Эти
ограничения подтолкнули к поиску новых решений.
Централизованные СКВ (1990-е)
Появление CVS (Concurrent Versions System) и
Subversion (SVN) стало значительным шагом вперёд.
Эти системы использовали центральный сервер для
хранения всего репозитория, что упрощало совместную
работу, но создавало единую точку отказа и требовало
постоянного сетевого подключения.

27.

Распределённые системы контроля версий
(DVCS): что это?
Полная копия репозитория
В отличие от централизованных систем, где разработчики получают лишь последнюю версию файлов, в DVCS
каждый участник имеет на своём локальном компьютере полную копию всего репозитория. Это включает в себя
всю историю изменений проекта со всеми ветками и коммитами.
Децентрализованная архитектура
Отсутствие единого центрального сервера — ключевая особенность DVCS. Разработчики могут обмениваться
изменениями напрямую друг с другом, публикуя свои локальные репозитории и извлекая изменения из
репозиториев коллег. Это создаёт более устойчивую и гибкую сеть.
Примеры популярных DVCS
Самыми известными представителями распределённых систем контроля версий являются Git, Mercurial и Bazaar.
Из них Git завоевал наибольшую популярность и стал стандартом де-факто в индустрии разработки программного
обеспечения благодаря своей производительности, гибкости и надёжности.

28.

Преимущества DVCS перед централизованными системами
Работа офлайн
Разработчики могут коммитить изменения, просматривать историю проекта, создавать ветки и выполнять
большинство операций контроля версий без активного сетевого подключения. Это обеспечивает непрерывность
работы и гибкость.
Надёжность
Отсутствие единой точки отказа. Поскольку каждый разработчик имеет полную копию репозитория, данные проекта
распределены и значительно снижается риск их потери. Если один репозиторий повреждён, его можно восстановить
из любой другой копии.
Приватная работа
Возможность создавать локальные ветки и коммитить черновые изменения без необходимости публиковать их на
центральный сервер. Это позволяет экспериментировать, не влияя на стабильность основной кодовой базы.
Ускорение операций
Большинство операций, таких как коммиты, просмотр истории и слияние веток, выполняются локально, что
значительно быстрее по сравнению с необходимостью каждый раз обращаться к удалённому серверу.

29.

Как работает Git — самая популярная DVCS
Git стал мировым стандартом благодаря своей мощности и гибкости. Его архитектура позволяет эффективно управлять
проектами любого масштаба.
Репозиторий: Сердце Git. Он содержит все файлы проекта, их полную историю изменений, информацию о коммитах, ветках
и тегах. Каждый разработчик клонирует весь репозиторий на свою локальную машину.
Основные команды:
git init: инициализирует новый репозиторий.
git add: добавляет изменения в индекс для следующего коммита.
git commit: сохраняет текущие изменения в локальном репозитории.
git push: отправляет изменения из локального репозитория в удалённый.
git pull: загружает изменения из удалённого репозитория в локальный.
Ветки и слияния: Git обеспечивает мощную модель ветвления, позволяющую разработчикам параллельно работать над
разными функциями или исправлениями ошибок. Затем эти ветки легко сливаются обратно в основную линию разработки.
Граф коммитов: Git хранит данные не как последовательность изменений, а как ориентированный ациклический граф
коммитов, где каждый коммит ссылается на предыдущие. Это делает систему чрезвычайно гибкой и эффективной для
отслеживания сложной истории проекта.

30.

Реальные кейсы и масштабы использования
Git и другие DVCS доказали свою эффективность в самых требовательных проектах и стали основой для крупнейших
технологических компаний и открытых сообществ.
Linux Kernel
Один из самых больших и активно
разрабатываемых открытых
проектов в мире, Linux Kernel, с
самого начала был разработан и
управляется с помощью Git,
созданного самим Линусом
Торвальдсом специально для этих
целей. Это является ярким
примером масштабируемости и
надёжности DVCS.
GitHub и Bitbucket
Крупные корпорации
Эти платформы стали центрами
притяжения для миллионов
разработчиков по всему миру. Они
используют Git в качестве
основной системы контроля
версий, предоставляя мощные
инструменты для совместной
работы, управления проектами и
хостинга репозиториев.
Такие гиганты, как Microsoft,
Netflix и Shopify, используют Git
для управления разработкой
своих продуктов. Это позволяет
им эффективно координировать
работу тысяч инженеров над
сложными, распределёнными
системами, обеспечивая высокую
скорость и качество выпуска ПО.

31.

Ограничения и вызовы DVCS
Время первичной загрузки
Требования к дисковому пространству
Из-за того, что каждый разработчик получает полную
копию репозитория с всей историей, первоначальное
клонирование большого проекта может занять
значительное время и потребовать большую
пропускную способность сети.
Аналогично, хранение полной истории на каждой
локальной машине подразумевает больший объём
дискового пространства. Для очень крупных проектов это
может стать проблемой, хотя современные инструменты
Git (вроде Git LFS) помогают управлять большими
бинарными файлами.
Сложности с бинарными файлами
Разрешение конфликтов слияния
DVCS, в частности Git, оптимизированы для текстовых
файлов. Управление бинарными файлами
(изображениями, видео, скомпилированными сборками),
которые часто не поддаются эффективному объединению
и хранению изменений, может быть более сложным и
требовать специальных подходов.
Хотя DVCS предоставляют мощные инструменты для
слияния, разрешение сложных конфликтов, особенно
при параллельной работе над одними и теми же
участками кода, всё ещё требует внимания и опыта
разработчиков.

32.

СПАСИБО
ЗА
ВНИМАНИЕ