Хорошая практика использования систем контроля версий в web-проектах
Я занимаюсь разработкой web-проектов сравнительно недавно. И с первых же дней работы мне пришлось столкнуться с системами контроля версий, и, как вы уже догадались, это был Subversion. Для меня сначала было не совсем понятно, что такое trunk, brunch и tag. Вернее, что это такое мне объяснили, а что с этим делать — нет.
Понимание пришло с первым коммерческим проектом. В этом проекте уже была создана структура хранилища svn, но пройдясь по ревизиям и просмотрев изменения, я заподозрил неладное. Каково же было мое удивление, когда на вопрос к коллегам, как должна правильно выглядеть структура svn, никто не смог дать мне более или менее вразумительного ответа, а по некоторым вопросам разгорелся настоящий холивар.
Это статья рассчитана в основном на начинающих программистов. Но как показала практика, некоторые разработчики с опытом работы более 1-2 лет, так же не до конца понимают, как правильно организовать структуру svn.
Первое, о чем я хочу сказать — вы можете организовать структуру хранилища и работать со структурой так, как вам удобно. Но не нужно удивлять тех людей, которые будут работать в проекте после вас. Как и в любом деле — в организации структуры хранилища в svn существует хорошая практика, зарекомендовавшая себя временем. И об этой практике я хочу немного рассказать.
trunk, branch и tag — это директории в корне хранилища. Названия директорий условно и можно называть их как угодно, но лучше использовать принятое оглашение по наименованию.
trunk — основная директория хранилища, содержит самую последнюю версию проекта. Именно в этой директории работают все разработчики проекта.
branch — директория для хранения веток. Ветка — это одна из версий проекта. Ветки создаются из trunk'a как правило тогда, когда нужно реализовать какой-нибудь функционал, работа над которым займет продолжительное время. Иногда я создаю отдельную ветку, когда хочу поэкспериментировать с чем-нибудь, попробовать применить нестандартный подход и др. Вся прелесть веток в том, что своими экспериментами вы не можете никому навредить и повлиять на основной ход разработки. Если у вас получится то, что вы хотели, вы сможете без проблем перенести эти изменения в trunk. Если не получится — вы просто удалите эту ветку и это никак не скажется на работе остальной команды.
tag — директория для хранения меток. Метка — это тоже версия проекта. Метка нужна для фиксации состояния trunk'а во времени. Метки создаются только тогда, когда код в trunk'e протестирован и готов к релизу. Никогда не делайте изменений в метках — это плохая практика.
Продакшн сервер всегда смотрит на одну из меток, как правило на последнюю. Т.е. на одну из поддиректорий в tag. Почему? Все очень просто. В случае если на продкашен попадает баг, который пропустили на этапе тестирования, все что нужно сделать, чтобы вернуть проект к стабильному состоянию — переключится на предыдущую метку.
Тестовый сервер и сервер непрерывной интеграции — всегда смотрят на trunk. Почему? Опять все просто, trunk содержит последнюю версию кода, что помогает отловить баги на ранних этапах.
Девелоперские сервера должны смотреть на trunk, если работа ведется в обычном режиме или на одну из веток, если реализуется достаточно большой функционал. В случае работы с ветками главное правило — перед каждым коммитом не забывать переносить изменения из trunk'а.
Коммититься нужно часто. Только желательно, чтобы изменения не приводили к падению тестов. Поэтому большие задачи я разбиваю на мелкие подзадачи и делаю коммит по завершению каждой из них. Слишком часто коммититься, наверное, тоже не очень хорошо. Я стараюсь составлять список подзадач так, чтобы на выполнение каждой из них у меня уходило от двух до четырех часов. Таким образом у меня получается в среднем два-три коммита в день. В случае потери локальных изменений — я не потеряю много времени на то, чтобы восстановить их.
В больших проектах, которые состоят из нескольких модулей хорошей практикой является заведение отдельного хранилища для каждого модуля. Сами модули могут быть написаны на разных языках. Тут модули могут быть запущены на одном или разных серверах, могут тестироваться на разных серверах, тестироваться вместе или по отдельности. Преимуществ от этого подхода много.
К центральному модулю остальные могут быть подключены путем добавления внешних зависимостей. При этом зависимости можно будет легко изменить. Допустим подключить другую версию какого-нибудь модуля. Если же все хранится в одном хранилище — как не организовывай структуру — все равно получится каша.
Надеюсь, мой небольшой опыт в web-разработке, которым я захотел поделится оказался полезным, и вы не зря потратили несколько минут времени на эту статью.
Понимание пришло с первым коммерческим проектом. В этом проекте уже была создана структура хранилища svn, но пройдясь по ревизиям и просмотрев изменения, я заподозрил неладное. Каково же было мое удивление, когда на вопрос к коллегам, как должна правильно выглядеть структура svn, никто не смог дать мне более или менее вразумительного ответа, а по некоторым вопросам разгорелся настоящий холивар.
Это статья рассчитана в основном на начинающих программистов. Но как показала практика, некоторые разработчики с опытом работы более 1-2 лет, так же не до конца понимают, как правильно организовать структуру svn.
Первое, о чем я хочу сказать — вы можете организовать структуру хранилища и работать со структурой так, как вам удобно. Но не нужно удивлять тех людей, которые будут работать в проекте после вас. Как и в любом деле — в организации структуры хранилища в svn существует хорошая практика, зарекомендовавшая себя временем. И об этой практике я хочу немного рассказать.
1. Что такое trunk, branch и tag
trunk, branch и tag — это директории в корне хранилища. Названия директорий условно и можно называть их как угодно, но лучше использовать принятое оглашение по наименованию.
trunk — основная директория хранилища, содержит самую последнюю версию проекта. Именно в этой директории работают все разработчики проекта.
branch — директория для хранения веток. Ветка — это одна из версий проекта. Ветки создаются из trunk'a как правило тогда, когда нужно реализовать какой-нибудь функционал, работа над которым займет продолжительное время. Иногда я создаю отдельную ветку, когда хочу поэкспериментировать с чем-нибудь, попробовать применить нестандартный подход и др. Вся прелесть веток в том, что своими экспериментами вы не можете никому навредить и повлиять на основной ход разработки. Если у вас получится то, что вы хотели, вы сможете без проблем перенести эти изменения в trunk. Если не получится — вы просто удалите эту ветку и это никак не скажется на работе остальной команды.
tag — директория для хранения меток. Метка — это тоже версия проекта. Метка нужна для фиксации состояния trunk'а во времени. Метки создаются только тогда, когда код в trunk'e протестирован и готов к релизу. Никогда не делайте изменений в метках — это плохая практика.
2. Куда смотреть серверам
Продакшн сервер всегда смотрит на одну из меток, как правило на последнюю. Т.е. на одну из поддиректорий в tag. Почему? Все очень просто. В случае если на продкашен попадает баг, который пропустили на этапе тестирования, все что нужно сделать, чтобы вернуть проект к стабильному состоянию — переключится на предыдущую метку.
Тестовый сервер и сервер непрерывной интеграции — всегда смотрят на trunk. Почему? Опять все просто, trunk содержит последнюю версию кода, что помогает отловить баги на ранних этапах.
Девелоперские сервера должны смотреть на trunk, если работа ведется в обычном режиме или на одну из веток, если реализуется достаточно большой функционал. В случае работы с ветками главное правило — перед каждым коммитом не забывать переносить изменения из trunk'а.
3. Практика частых коммитов
Коммититься нужно часто. Только желательно, чтобы изменения не приводили к падению тестов. Поэтому большие задачи я разбиваю на мелкие подзадачи и делаю коммит по завершению каждой из них. Слишком часто коммититься, наверное, тоже не очень хорошо. Я стараюсь составлять список подзадач так, чтобы на выполнение каждой из них у меня уходило от двух до четырех часов. Таким образом у меня получается в среднем два-три коммита в день. В случае потери локальных изменений — я не потеряю много времени на то, чтобы восстановить их.
4. Большие проекты
В больших проектах, которые состоят из нескольких модулей хорошей практикой является заведение отдельного хранилища для каждого модуля. Сами модули могут быть написаны на разных языках. Тут модули могут быть запущены на одном или разных серверах, могут тестироваться на разных серверах, тестироваться вместе или по отдельности. Преимуществ от этого подхода много.
К центральному модулю остальные могут быть подключены путем добавления внешних зависимостей. При этом зависимости можно будет легко изменить. Допустим подключить другую версию какого-нибудь модуля. Если же все хранится в одном хранилище — как не организовывай структуру — все равно получится каша.
Надеюсь, мой небольшой опыт в web-разработке, которым я захотел поделится оказался полезным, и вы не зря потратили несколько минут времени на эту статью.
0 комментариев