Системы контроля версий

Порядок | Удаленная работа | Ветки | Взаимодействие | Интеграция | Git

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

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

Порядок

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

  • логическую структуру проекта
  • управление доступом
  • хранение истории изменений

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

Удаленная работа

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

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

Ветки

Поддержка нескольких веток разработки внутри единого проекта делает возможным:

  • работу одним программистом над несколькими задачами одновременно
  • параллельную командную разработку нескольких функциональных возможностей
  • поддержку legacy–кода
  • мгновенное, изменение кода и контекста выполнения программы, необходимых для отката до последней корректной версии на рабочем сервисе

Обычно мы держим несколько веток кода.

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

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

Отдельная ветка предназначается для "боевого" кода. После того, как код в основной ветке будет готов к выпуску, он заменяет продакшн.

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

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

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

Взаимодействие

С помощью CVS программисты просматривают код друг друга и по мере надобности внедряют его в свой собственный.

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

Еше более изящный вариант синхронизации подкладывает основную ветку под ветку разработки таким образом, чтобы код выглядел линейным, как будто сначала появлялись изменения основной ветки, а после них произошли изменения из рабочей ветки программиста. Эту процедуру система управления версиями позволяет сделать одной командой. В случае отсутствия CVS, потребовался бы сложный механизм вычисления дельты, создания вручную патчей и накладывания их на рабочую ветку.

Проекты используют сторонние библиотеки. У таких библиотек есть несовместимые между собой версии. Не каждая версия библиотеки удачно сочетается с кодом разрабатываемого приложения. Система контроля версий позволяет сопоставлять каждой версии нашего проекта конкретную версию библиотеки. Таким образом можно быть уверенным, что разрабатываемый нами проект будет всегда в рабочем состоянии, вне зависимости от текущих творческих изысканий сторонних разработчиков.

Системы контроля версий предназначены не только для работы программиста. Заказчику также придется освоить этот инструмент, так как редкая работа обходится без вмешательства в материалы проекта со стороны заказчика. Но CVS это тот инструмент, время потраченное на овладение которым, не пропадет зря, поскольку открываемые им возможности находят применение во многих областях повседневной бизнес–деятельности.

Интеграция

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

В Nixteam триггеры применяются для:

  • уведомлений о появлении изменений в хранилище
  • автоматического закрытия тикетов в баг–трекере
  • проверки кода на соответствие внутренним стандартам кодирования
  • подтверждения проведения тестирования
  • обновления документации
  • настройки программного окружения

Git

В своей работе мы отдаем предпочтения системе контроля версий Git. Git является бесплатной, открытой, распределенной CVS. На нем работает масса проектов, в том числе:

  • Linux Kernel
  • Perl
  • PHP
  • Android
  • Qt

Существуют клиенты git для различных платформ, что имеет немаловажное значение, когда разработка ведется в гетерогенной среде. Основной сервер мы всегда держим под управлением Linux, но клиенты могут работать также на Windows и Mac OsX.

Распределенная архитектура Git дает ряд преимуществ перед централизованными хранилищами, такими как Subversion:

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

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

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

Хеширование объектов хранилища, используемое в Git, предотвращает появление ошибок, связанных с операциями ввода–вывода такими, как передача данных по сети и запись на жесткий диск.

На сегодняшний день Git является лучшим решением в своем классе. Именно поэтому мы в Nixteam работаем именно на нем.

Интеллект — это способность избегать выполнения работы, но так, чтобы она при этом была сделана.

Линус Торвальдс