Як зберігати проекти в сховище коду в блозі особистий досвід розробки по

Проект складається як зі свого коду, так і з бібліотек сторонніх розробників. Природно виникає питання як зберігати це добро. На це питання я спробую дати рекомендації на підставі власного досвіду.

  • Розробник повинен швидко приступити до роботи не забиваючи голову установкою десятка бібліотек.
  • Бібліотеки повинні бути доступні з різних проектів, при цьому необхідно уникнути дублювання коду в репозиторіях.
  • Повинна бути можливість зберігати певні стану проекту: нові версії, номерні збірки для тестерів і т.д.

Перед прочитанням настійно рекомендую ознайомитися з попередньою заміткою.

Я рекомендую під кожен проект створювати свій репозиторій. Це дозволить чітко відокремити один проект від іншого, при необхідності дати права на редагування конкретних репозиторіїв тільки певним розробникам, вирішити питання з архівуванням. Бібліотеки, навіть сторонні, слід розглядати як окремі проекти і також зберігати в окремих репозиторіях. Виняток може бути зроблено тільки для особливо великих бібліотек, наприклад Qt або Boost.

Subversion дозволяє встановити залежності між проектами, встановивши залежність проекту від інших проектів. Таким чином, одночасно з отриманням проекту зі сховищ можливо отримати весь необхідний для роботи код автоматично, не ускладнюючи життя установкою декількох бібліотек і відстеженням їх актуальності.

Папки trunk, tags, branches

Часто в Subversion використовують структуру проекту з трьох папок: trunk, tags і branches. Для чого вони?

  • trunk - це папка для розробки. У ній завжди знаходиться найсвіжіша версія коду, доступна для розробників. Тут вкрай важливо завжди підтримувати код в собірабельном стані. Будь-яка поломка збірки проекту повинна виправлятися якомога швидше, щоб не створювати складнощів іншим розробникам.
  • У tags знаходяться стану проекту на певний момент. Наприклад ближче до релізу, розробники починають створювати з певною періодичністю складання з унікальним номером які передаються тестерам. Стан проекту на цей момент можна зафіксувати в папці tag, присвоївши йому говорить назва, наприклад build_723. Це дозволить у разі внесення дефекту відсутнього в даній збірці і виявленого в наступній збірці, проаналізувати причину проблеми і вжити відповідних заходів до її устраненію.Также тут можна відзначати випущені версії, наприклад 1.0.5. Таким чином, отримавши від користувачів скаргу на помилку в будь-якої версії, можна взяти код актуальний для даної версії, для вивчення проблеми.
  • branches - тимчасові гілки розробників. Що це означає? Розробник Вася отримує завдання на додавання деякої функціональності. Для того щоб не блокувати роботу інших членів команди, він створює копію проекту в branches / vasia_task_1234, працює в цій гілці періодично зберігаючи код з репозиторій. Виконавши завдання, він проводить злиття з основною гілкою розробки (trunk) і видаляє тимчасову гілку. Завдання виконано, при цьому він міг фіксувати стан своєї роботи в тимчасовій гілці, не порушуючи роботи інших розробників.

Робота з гілками і фіксація стану проекту в tags буде описана в іншій замітці.

Як назвати версії?

Я пропоную спосіб нумерації версій складається з трьох цифр - major .minor .micro. де:

major - цифра позначає версію продукту (різні номери версій позначають суттєві відмінності між продуктами),
minor - підверсія продукту (різні номери говорять про те, що підверсії володіють різним функціоналом),
micro - в рамках підверсії вказує на те, що були виправлені будь-які помилки.

  1. При випуску нової версії містить тільки виправлення помилок збільшується цифра в позиції micro.
  2. При випуску версії зі зміненим функціоналом инкрементируется minor і обнуляється micro.
  3. При випуску нової версії продукту істотно відрізняється від попереднього, збільшується major, а minor і micro обнуляються.

приклад проекту

Розглянемо простий проект складається власне з коду проекту (project) і двох бібліотек (lib1, lib2). Структура з трьох сховищ:

branches
tags
trunk

branches
tags
trunk

Власне project - це наш проект, який залежить від сторонньої бібліотеки lib1 версії 1.0 і від бібліотеки власної розробки lib2, яка розробляється спільно з самим проектом, тому залежність буде від її основної гілки розробки (trunk).

Встановлюємо залежності в Subversion

Зверніть увагу на. - це говорить про те, що треба показати властивості встановлені для папки (деякі властивості можна встановити тільки для конкретних файлів).

Для редагування та додавання властивостей існує команда

Для установки властивості svn: externals (природно для всієї папки) перебуваючи в папці з основною гілкою розробки (путь_на_локальной_машіне / project / trunk) виконайте

Видалити властивість можна командою

Схоже на те. Тепер кожен раз забираючи код project зі сховищ буде одночасно довантажуватися код бібліотек. Якщо в бібліотеках були зроблені зміни, то вони автоматично оновляться. Таким чином прописавши залежності проекту можна не думати про бібліотеки, вони будуть оновлені і завантажені автоматично, основна гілка розробки буде містити папки lib1 і lib2 з бібліотеками.

Наступний закономірний етап - автоматично збирати необхідні бібліотеки разом з проектом, про що я скоро розповім на прикладі кроссплатформенного інструменту автоматизації збирання CMake.

Схожі статті