Опыт внедрения системы контроля версий в веб-студии - Часть 1
Автор: Конкин Е.Е.
Заранее извиняюсь перед коллегами, что будет много букв. Возможно все, что написано ниже окажется громоздким и неудобным, но уверяю, что это впечатление обманчиво. Я постарался описать доступно, но, разумеется, охватил не все аспекты.
Как известно мозг человека может одновременно контролировать 3-5 разных задач, и лишь у гениев эта цифра может дойти до 7-10. В нашей с вами работе эта цифра намного выше, а значит необходимо было использовать инструменты, которые смогут всё максимально стандартизировать и упорядочить.
Проблему совместной работы над проектами и контроля за вносимыми изменениями помогает устранить система контроля версий (Version Control System – VCS), которая позволяет решить многие насущные проблемы работы над проектами веб-студии. В частности, в ней можно отследить характер вносимых в проект изменений, временной отрезок, в котором они были сделаны, кем сделаны и так далее. В случае неудачи, можно будет вернуться к какой либо зафиксированной точке проекта, либо распараллелить разработку на разные «ветки». Благодаря системе контроля версий упрощается совместная разработка одного проекта, ведь изменения, вносимые в рамках одной задачи одним разработчиком, не будут затирать изменения вносимые другим.
Что мы имели на момент начала внедрения VCS
На тот момент мы имели локальный сервер, файловая система которого расшарена в общий доступ по сети. Такой вариант разработки более менее удобен, до поры до времени, пока не встает вопрос о совместной работе над проектом. Помимо этого проекты никак «физически» не были связаны с системой управления проектами Redmine. Все это было доставляло не мало неудобств, а в случае возникновения проблем возникала ненужная возня для их устранения.
С чего мы начали систему внедрения контроля версий
Перейдем к вопросу практики. Как всё правильно организовать? Необходимые инструменты:
1) Локальный сервер в общем доступе. Конечно, лучшим вариантом является организация своего unix сервера — это даст Вам в дальнейшем больше гибкости, но если Вы не сильно любите заниматься системным администрированием или Ваши запросы к серверу не очень велики, то подойдет обычная сборка OpenServer. Его пользовательский интерфейс без проблем позволит сконфигурировать сервер под начальные нужды веб-студии.
2) Система управления проектами – Redmine.
3) Система контроля версий – выбран Git. В принципе, рассматривались: Git и Mercurial. Популярна система SVN, но она является централизованной, и у этого есть свои минусы, которые я не буду описывать в рамках данной статьи. Mercurial и Git системы распределенные, и чисто субъективно с первой у меня в процессе работы возникло меньше проблем. Однако для веб-студии все же был выбран Git. Во-первых, большее количество хостингов по умолчанию работают с git, а во-вторых, git оказал меньшее сопротивлении при связывании VCS и Redmine.
4) Локальный сервер на компьютере программиста (подойдет и самый обычный Denwer). Для запуска локальных (клонированных) копий проекта.
Здесь всплывают достоинства распределенной системы. Разработка ведется у себя на компьютере, периодически сливаясь в центральный репозиторий расположенный на сервере, чтобы изменения вышли в общий доступ.
5) Графический инструмент для удобной работы с системой контроля версий. Как истинные программисты, мы конечно могли бы пользоваться «хардкорной» консолью, но с GUI будет поприятнее. Вариант — Tortoise (для Mercurial), она проста в использовании для начинающих. В результате выбрана и используется - SourceTree, которая субъективно понравилась больше. Кому, что нравится, как говорится.
6) Bitbucket.org. Bitbucket это удаленное хранилище кода. Там мы будем хранить код актуальный для всех веток, участвующих в разработке.
На первом этапе - всё. Это был локальный подготовительный этап.
Как мы теперь работаем с системой контроля
У нас все установлено и мы готовы к работе. Последовательность работы следующая:
1) Создаем проект в Redmine. Для нас важен модуль хранилища.
2) Перед началом работы над новым сайтом (либо его частью) ответственный программист на битбакете создает репозиторий.
3) Создаем центральный репозиторий на OpenServer. Используем для этого SourceTree. В обычном порядке разворачиваем на сервере необходимую cms. Создаем репозиторий Git. При создании репозитория указывается путь к залитой структуре файлов CMS.
Репозиторий создан, однако он пуст. Необходимо добавить файлы к индексации. Для удобства мы индексируем всю cms, хотя бывают случаи когда это не нужно, возможно нам необходимо модернизировать один компонент и больше ничего, тогда есть смысл добавить в индексацию только папку с этим компонентом. Делаем «коммит» - фиксацию файлов. Коммиты - важная и наиболее используемая команда. Существует пара правил, которые необходимо придерживаться при коммитах. Настраиваем .gitignore по необходимости. Обязательно туда включить папки кеша. Возможно если разрабатывается часть сайта, то не нужно контролировать весь сайт. Достаточно лишь часть его папок. Важно создать .gitignore до создания репозитория. Иначе система начнет индексировать все файлы (включая тонны кеша и нехило подвиснет, да и в дальнейшем при фиксации изменений будет притормаживать).
Немного о правилах хорошего тона в коммитах:
А) К коммиту всегда пишется поясняющее сообщение. Оно должно четко отражать суть внесенных изменений. Хороший коммит: «Исправлен вывод цен товара в компоненте корзины». Плохие коммиты: «Исправлена ошибка в корзине» (какая?), «Убран баг верстки» (где?), «агрыдбалфв» (без комментариев).
Б) Коммит должен быть атомарен. То есть относиться к сути какого-то одного действия в репозитории. Не стоит писать «Исправлена вся верстка на сайте» и модернизировать миллиард файлов разом. Лучше сделать несколько коммитов «Исправлена верстка корзины», «Исправлена верстка слайдера» и т.д.
Итак, делаем коммит.
Теперь нужно выгрузить реопзиторий на битбакет. Делается это так. При создании проекта в redmine, вы указываете, что у вас уже имеется существующий проект и выполняете указанные на bitbucket консольные команды прямо из SourceTree.
Получаем первый узел в дереве изменений:
Сверху загорелась кнопка Push. Это означает, что есть изменения (коммиты), которые имеются на локальной копии, но отсутствуют на центральной. Нажимаем.
В реальной работе нет смысла делать Push после каждого коммита. Можно вести разработку у себя весь день, и вытолкнуть в конце дня на общий сервер. Плюс ко всему в реальном случае перед выталкиванием необходимо сделать затягивание изменений с сервера (Pull), чтобы в случае возникновения правок одних и тех же файлов разными разработчиками можно было провести слияние изменений (Merge) перед выгрузкой (Pull). Более подробно о репозитории читаем в интернете, там рассказано, что такое ветки, как правильно всем этим пользоваться и «почему пуш выдает ошибку».
Теперь на центральном сервере имеется репозиторий, который может себе клонировать (clone) другой программист для дальнейшей работы с ним.
Клонирование репозитория программист делает себе в папочку на локальный сервер, чтобы можно было там разрабатывать. При этом конфигурационный файл, который отвечает за настройки доступа можно не включать в первый коммит для индексирования. Он у всех будет разный. В этой клонированной копии на денвере мы работаем, коммитим, иногда пушим на общий сервер.
4) Вернемся к redmine.
Заходим в настройки проекта и создаем новое хранилище.
Тип хранилища выбираем Git. Путь к хранилищу - штука привередливая. Чтобы работало все нормально, нужно прописать полный путь к проекту на машине центрального сервера. То есть типа того: C:/OpenServer/domains/develop/<имя проекта>/.git
На этом все. Проект привязан. Обновление здесь будет происходить только при обновлении репозитория центрального сервера.
Можно пользоваться. Redmine интегрирован в репозиторием.
На этом локальный этап заканчивается. Во второй части статьи я расскажу про этап - деплоймент сайта (перенос на рабочий хостинг с сохранением репозитория).
