Работа с системой управления версиями при Agile разработке

737
-1

Published on

Работа с системой управления версиями при Agile разработке

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
737
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Работа с системой управления версиями при Agile разработке

  1. 1. Работа с системой управления версиями при Agile разработке Малышкин Фёдор ( [email_address] ) 2 5 апреля 2008
  2. 2. Использование SCM <ul><li>История использования SCM (Software Configuration Management) , в нашей фирме, имеет очень глубокие корни, но очень простые принципы: сохраняйся и обновляйся чаще. </li></ul><ul><li>В большинстве случаев оно используется как: </li></ul><ul><ul><li>Хранилище исходных текстов и ресурсов программ </li></ul></ul><ul><ul><li>Средство обмена исходными текстами (синхронизации работы) </li></ul></ul>
  3. 3. Проблемы <ul><li>«Нерабочие» версии проекта в репозитарии («Я тут поломал, поэтому показать не могу…») </li></ul><ul><li>Конфликты при «коммите» </li></ul>
  4. 4. Цели презентации <ul><li>Отказоустойчивость </li></ul><ul><ul><li>Конфликты в коде могут быть обнаружены как можно раньше </li></ul></ul><ul><ul><li>Исправление маленьких проблем (возможно чаще), чем больших (возможно реже) </li></ul></ul><ul><li>Всегда рабочее состояние </li></ul><ul><ul><li>Даже после большой неудачной работы в репозитарии есть рабочая копия чего-то </li></ul></ul><ul><li>Простота </li></ul><ul><ul><li>Все члены команды используют одну и ту же схему изо дня в день, как следствие все процедуры ясны и понятны </li></ul></ul>
  5. 5. Диаграмма
  6. 6. Проблемы применения схемы <ul><li>Несколько задач реализуются в ветке параллельно . </li></ul><ul><li>Другая команда также производит публикацию в trunk. </li></ul><ul><li>Ожидание пока параллельная задача будет закончена или пока другая группа применит Ваши изменения, не может рассматриваться как решение. Это будет подобно снежному кому – поэтому необходимо выработать некоторые правила. </li></ul>
  7. 7. Несколько задач реализуются в ветке параллельно . Варианты. <ul><li>Не делать задач параллельно в рамках одно группы. Пытаться фокусироваться на одной задаче. </li></ul><ul><li>Если кто-то собирается начать параллельную работу – подождать пока предыдущая задача будет опубликована. Либо создать новую ветку для неё (если нравится жонглировать ветками). </li></ul><ul><li>Если кто-то начинает параллельную работу и она требует изменения существующего кода – начинайте с создания нового кода (новые классы, новые методы, новые тесты), но без модификаций существующего кода. Как только первая работа будет опубликована – можно начинать изменять код. </li></ul>
  8. 8. Правила <ul><li>Кто бы не трогал trunk – он ответственен за работоспособность основной ветви. Включая весь предыдущий функционал! </li></ul><ul><li>Синхронизируйте вашу ветвь с основной периодически ( = как можно чаще) </li></ul>
  9. 9. Другая команда также производит публикацию в trunk. Правила. <ul><li>Синхронизируйте вашу ветвь с основной ежедневно (как минимум). </li></ul><ul><li>Сразу разрешайте проблемы на вашей рабочей ветви. </li></ul><ul><li>Объединяйте Вашу рабочую ветвь с основной на периодической основе. Например по окончании задачи (разумеется нерабочий или «ломающий» код выкладывать нельзя). Не ждите окончания спринта. </li></ul><ul><li>Тот кто первый объединил – выиграл. В случае возникновения конфликтов при слиянии – он их исправлять уже не будет. Будет тот, кто производил слияние последним. </li></ul>
  10. 10. Диаграмма
  11. 11. Дополнительные возможности <ul><li>Ветви версий с различным функционалом </li></ul><ul><li>Неизменяемы версии ( tags ветка) </li></ul>
  12. 12. Ресурсы <ul><li>«Управление версиями в Subversion» - отличная книга по svn ( есть в электронном виде, на русском ) </li></ul>

×