Автоматизация разработки

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

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

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

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

Примечательно, что объемы хранилищ истории увеличиваются не столь катастрофично, поскольку изменения файлов запоминаются в виде приращений, т. е. запоминается не вся новая версия файла, а только то его место, которое изменилось (например, строчка с исправленной ошибкой). Особенно эффективно в этом смысле хранение текстовых файлов, а не двоичных.

Изначально системы контроля версий были централизованными (CVS, Subversion и пр.), т.е. хранилища истории располагались на сервере, а пользователи копировали из него временный срез (фиксацию, commit) проекта на локальные компьютеры, модифицировали файлы и фиксировали изменения в хранилище сервера.

Со временем все более популярными становятся т.н. распределенные системы контроля версий (Git, Mercurial, Bazaar и др.). Такие системы на каждом локальном компьютере хранят не отдельный временной срез проекта, а всю его историю целиком. Другими словами, каждое локальное хранилище содержит полный объем информации и является равноправным по отношению к остальным хранилищам. Такие системы менее уязвимы и в определенном смысле более удобны. При этом вполне допустимо хранить одно из таких хранилищ на сервере и условно называть его центральным (так чаще всего и делают). Не все ветви разработки обязаны вноситься в центральное хранилище. Например, экспериментальные ветви м. б. закрыты и оставлены на локальных компьютерах, чтобы не засорять основной проект.

Как правило, системы контроля версий управляются с командной строки, но для них имеется множество графических оболочек (Tortoise, QGit, SmartSVN, Giggle и др.). Многие системы контроля версий интегрированы в среды разработки (NetBeans IDE, Eclipse, Microsoft Visual Studio, Qt Creator и пр.). Пользуются популярностью сервисы, предоставляющие возможность расположения хранилищ в Интернете (GitHub, Bitbucket, SourceForge, Google Code, Launchpad и др.). Множество известных проектов пользуются подобными услугами (Linux, Android, Ruby on Rails, Qt, Joomla!, PHP, Mozilla, OpenOffice, Netbeans, OpenSolaris, Facebook, Yahoo, Twitter, Perl и пр.). Исходные коды большинства проектов открыты. Любой пользователь Интернета имеет возможность получить не только полную версию текстов программ со всей историей, но и стать полноправным участником разработки.

Системы контроля версий нередко интегрируются с системами управления проектами (Redmine, Trac, Bugzilla и пр.). Такие системы позволяют планировать и отслеживать разработку, назначая задачи, приоритеты, ответственных исполнителей и т.п.

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

3.3 Когда базар строит собор [16]