Определить цели и задачи коллективной разработки программного обеспечения Вашей задачи автоматизации, уяснить требования, предъя. Отчет по практической работе 1 по дисциплине Технологии разработки программного обеспечения
 Скачать 112.72 Kb.
|
Институт Информационных технологий Кафедра Математического обеспечения и стандартизации информационных технологий
Москва 2021 Что такое контроль версий, и зачем он нужен? Система управления версиями (также используется определение «система контроля версий», от англ. Version Control System, VCS или Revision Control System) — программное обеспечение для облегчения работы с изменяющейся информацией. Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение, и многое другое. Модели хранения данных Примитивная модель хранения версий. В примитивной модели актуальные копии проекта перезаписываются в отдельную директорию через определённый промежуток времени. У данной модели есть достоинство: возможность восстановления данных одной из записанных версий. К недостаткам можно отнести: сложности с поиском необходимой версии в обширной и плохо структурированной базе данных; возможность потери данных вследствие возникновения физических поломок оборудования; отсутствие возможности совместной разработки. Локальные системы контроля версий. Для решения части из этих проблем были разработаны локальные СКВ. Одной из первых и наиболее популярных СКВ такого типа являлась RCS, которая была разработана в 1985 году. Для каждого файла, зарегистрированного в системе, она хранит полную историю изменений, причём для текстовых файлов используется эффективный алгоритм дельта-компрессии, когда хранится только последняя версия и все межверсионные изменения. Такие СКВ решали только первую проблему - избыточность данных.  Рисунок 1 - Локальные СКВ Современные СКВ можно разделить на две группы: централизованные и распределенные. Централизованные системы контроля версий. Следующей основной проблемой оказалась необходимость сотрудничать с разработчиками за другими компьютерами. Чтобы решить её, были созданы централизованные системы контроля версий (ЦСКВ). В таких системах, например CVS, Subversion и Perforce, есть центральный сервер, на котором хранятся все файлы под версионным контролем, и ряд клиентов, которые получают копии файлов из него. Много лет это было стандартом для систем контроля версий. Такой подход имеет множество преимуществ, особенно перед локальными СКВ. К примеру, все знают, кто и чем занимается в проекте. У администраторов есть чёткий контроль над тем, кто и что может делать, и, конечно, администрировать ЦСКВ намного легче, чем локальные базы на каждом клиенте. Однако при таком подходе есть и несколько серьёзных недостатков. Наиболее очевидный — централизованный сервер является уязвимым местом всей системы. Если сервер выключается на час, то в течение часа разработчики не могут взаимодействовать, и никто не может сохранить новой версии своей работы. Если же повреждается диск с центральной базой данных и нет резервной копии, вы теряете абсолютно всё — всю историю проекта, разве что за исключением нескольких рабочих версий, сохранившихся на рабочих машинах пользователей. Локальные системы контроля версий подвержены той же проблеме: если вся история проекта хранится в одном месте, вы рискуете потерять всё.  Рисунок 2 - Централизованные СКВ Распределённые системы контроля версий. И в этой ситуации в игру вступают распределённые системы контроля версий. В таких системах как Git, Mercurial, Bazaar или Darcs клиенты не просто выгружают последние версии файлов, а полностью копируют весь репозиторий (репозиторий, в простонародье репа, это место, где хранятся и поддерживаются какие-либо данные). При этом можно выделить центральный репозиторий (условно), в который будут отправляться изменения из локальных и, с ним же эти локальные репозитории будут синхронизироваться. Поэтому в случае, когда "умирает" сервер, через который шла работа, любой клиентский репозиторий может быть скопирован обратно на сервер, чтобы восстановить базу данных. Каждый раз, когда клиент забирает свежую версию файлов, он создаёт себе полную копию всех данных. Кроме того, в большей части этих систем можно работать с несколькими удалёнными репозиториями. На сегодняшний день стандартом де-факто стала распределенная система контроля версий - GIT, но в старых больших проектах вполне могут встретиться устаревшие СКВ (например, популярная в свое время Subversion).  Рисунок 3 - Распределенные СКВ Основы GIT Почти все операции — локальные. Для совершения большинства операций в Git'е необходимы только локальные файлы и ресурсы, т.е. обычно информация с других компьютеров в сети не нужна. К примеру, чтобы показать историю проекта, Git'у не нужно скачивать её с сервера, он просто читает её прямо из вашего локального репозитория. Поэтому историю вы увидите практически мгновенно. Если вам нужно просмотреть изменения между текущей версией файла и версией, сделанной месяц назад, Git может взять файл месячной давности и вычислить разницу на месте, вместо того чтобы запрашивать разницу у СКВ-сервера или качать с него старую версию файла и делать локальное сравнение. Кроме того, работа локально означает, что практически все можно сделать без доступа к Сети. Если вы в самолёте или в поезде и хотите немного поработать, можно спокойно делать коммиты, а отправить их, как только станет доступна сеть. Во многих других системах это невозможно или же крайне неудобно. Например, используя Perforce, вы мало что можете сделать без соединения с сервером. Работая с Subversion и CVS, вы можете редактировать файлы, но сохранить изменения в вашу базу данных нельзя (потому что она отключена от репозитория). Git следит за целостностью данных. Перед сохранением любого файла Git вычисляет контрольную сумму, и она становится индексом этого файла. Поэтому невозможно изменить содержимое файла или каталога так,чтобы Git не узнал об этом. Эта функциональность встроена в сам фундамент Git'а и является важной составляющей его философии. Если информация потеряется при передаче или повредится на диске, Git всегда это выявит. Чаще всего данные в Git только добавляются. Практически все действия, которые вы совершаете в Git'е, только добавляют данные в базу. Очень сложно заставить систему удалить данные или сделать что-то неотменяемое. Можно, как и в любой другой СКВ, потерять данные, которые вы ещё не сохранили, но как только они зафиксированы, их очень сложно потерять, особенно если вы регулярно отправляете изменения в другой репозиторий. Три состояния файлов. В Git'е файлы могут находиться в одном из трёх состояний: зафиксированном, изменённом и подготовленном. "Зафиксированный" значит, что файл уже сохранён в вашей локальной базе. К изменённым относятся файлы, которые поменялись, но ещё не были зафиксированы. Подготовленные файлы — это изменённые файлы, отмеченные для включения в следующий коммит. Различные системы контроля версий Существует несколько моделей хранения данных: Локальные системы контроля версий Локальные СКВ обычно хранят на компьютере список изменений, внесенных в файлы. Основываясь на этих данных, система контроля версий воссоздает нужную версию файла (актуальную на определенный момент времени). Достоинства: возможность восстановления данных из определенной версии (точно определяется по времени записи); высокая скорость выполнения восстановления (база данных четко структурирована, поэтому сложностей при поиске не возникает, сетевая задержка отсутствует, поскольку данные хранятся непосредственно на рабочем компьютере). Недостатки: возможность потери данных вследствие возникновения физических поломок оборудования; отсутствие возможности совместной разработки. Централизованные системы контроля версий Централизованные системы контроля версий предполагают сохранение версий проектов на общий сервер, с которого потом получают нужные версии клиенты. Достоинства: возможность восстановления данных из определенной версии (точно определяется по времени записи); возможность ведения командной разработки проекта; Недостатки: отсутствие доступа к данным при сбое работы сервера; довольно низкая скорость работы (из-за возникновения сетевых задержек). Децентрализованные системы контроля версий В децентрализованных системах контроля версий при каждом копировании удалённого репозитория (расположенного на сервере) происходит полное копирование данных в локальный репозиторий (установленный на рабочем компьютере). Каждая копия содержит все данные, хранящиеся в удалённом репозитории. В случае, возникновения технической неисправности на стороне сервера, удаленный репозиторий можно перезаписать с любой сохраненной копии. Достоинства: возможность восстановления данных из определенной версии (точно определяется по времени записи); возможность ведения командной разработки проекта; при сбое работы сервера система сохраняет данные в локальном репозитории, что позволяет эффективно вести процесс разработки, а после восстановления работы сервера, передать все изменения в удаленный репозиторий; при физической поломке сервера данные можно легко перенести в новый удалённый репозиторий с любого локального репозитория; высокая скорость работы (в ходе работы данные записываются и получаются из локального репозитория, поэтому сетевые задержки отсутствуют). Существует много систем контроля версий (Git, Darcs, Mercurial, Bazaar, Monotone и т.д), сходных по принципу работы и конечным задачам. Отличаются они друг от друга архитектурой, использованными решениями и удобством работы. Самая популярная на сегодняшний день система контроля версий – Git. Git – распределённая система контроля версий. Что даёт ей все преимущества децентрализованной СКВ: высокую скорость проведения всех операций (за счет отсутствия сетевой задержки); идеальные условия для командной разработки; страховку от потери информации при возникновении проблем с центральным сервером. Для контроля версий в git используются 2 репозитория: локальный и удаленный. Локальный репозиторий (полноценный репозиторий, а не ссылки или копии отдельных ветвей) находится на компьютере разработчика, а удаленный на удалённом сервере. Доступ к удаленному репозиторию обеспечивается благодаря гит-хостингу Github, Google Code, GitLab и т.д. Особенности Git Взаимодействие с удаленным репозиторием происходит при наличии интернета и, по сути, представляет собой синхронизацию двух репозиториев. Команда push копирует новые данные, содержащиеся в локальном репозитории, в удалённый репозиторий, а команда pull передает данные из удаленного репозитория в локальный. Каждая версия документа, внесенные обновления и т.д записываются в локальный репозиторий. В репозитории содержится «дерево» проекта, то есть все сохраненные версии файлов. Дерево может быть прямым (в этом случае каждое последующее сохранение файлов производилось после предыдущего без возвращения к более ранним версиям) и разветвленным. К появлению «веток» приводит работа с более ранними версиями и сохранение внесённых изменений. На различных ветках дерева содержатся сохранения, основой которых был один исходный файл. В ходе работы в файлы на разных ветках были внесены разные изменения. В системе управления версиями можно работать со всеми ветками дерева проекта, пошагово, изменяя и дополняя содержащиеся в них данные. После проведения ряда изменений 2 ветки могут «срастись», в новой версии файла будут учтены все внесенные изменения. Для комфортной работы с git нужно зарегистрироваться на любом git-хостинге. Их довольно много: Github, Sourceforge, Google Code, GitLab, Codebase и т.д. Самый популярный на данный момент git-хостинг – это Github. Для удобства работы с системой контроля версий git разработан целый ряд графических git-клиентов. Это программы, позволяющие эффективно работать с системой контроля версий, используя графический интерфейс. Многие IDE предполагают возможность работы с git. Например, GitHub Desktop. Вывод: Ознакомились с системами контроля версий, их различием и применением. Системы контроля версий необходимая часть любой коллективной разработки ПО. Список литературы 1. Git. Просто Git. Лекция 1. Введение. [Электронный ресурс] // zzet.org. URL: http://www.mga.ru. (Дата обращения: 17.11.2021) 2. Системы контроля версий — основа командной разработки. [Электронный ресурс] // Школа программирования ProgTips. URL: https://progtips.ru/instrumenty-programmista/sistemy-kontrolya-versij-osnova-komandnoj-razrabotki.html. (Дата обращения: 17.11.2021) 3. Что такое контроль версий? [Электронный ресурс] // Bitbucket. URL: https://www.atlassian.com/ru/git/tutorials/what-is-version-control. (Дата обращения: 17.11.2021) | ||||||||||||||||||||||||||||||
