04 - Agile Software Configuration Management
•Télécharger en tant que PPTX, PDF•
4 j'aime•2,621 vues
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à 04 - Agile Software Configuration Management
Similaire à 04 - Agile Software Configuration Management (20)
Plus de Sergii Shmarkatiuk
Plus de Sergii Shmarkatiuk (10)
Dernier
Dernier (20)
04 - Agile Software Configuration Management
- 1. AGILE SOFTWARE CONFIGURATION MANAGEMENT
- 2. INTRODUCTION 2 General conventions and ideas
- 3. 3
- 4. GOAL CONNECTION BETWEEN: 1. AGILE-METHODOLOGIES AND CONFIGURATION MANAGEMENT PRACTICES 2. TOOLS UTILIZED BY SOFTWARE CONFIGURATION MANAGEMENT PRACTICES Version control Build & Versions deployment numbering management Agile SCM 4 Release Continuous management integration
- 5. NARRATION FROM SIMPLE TO COMPLEX… 5
- 6. NARRATION …WITH SIMULTANEOUS ELIMINATION OF EMERGING CONTRADICTIONS 6
- 7. REPRESENTATION STREAMLINE DIAGRAMS 7
- 8. REPRESENTATION STREAMLINE DIAGRAMS 8
- 9. REPRESENTATION STREAMLINE DIAGRAMS 9
- 10. REPRESENTATION STREAMLINE DIAGRAMS 10
- 11. REPRESENTATION STREAMLINE DIAGRAMS branches releases builds tags merges directories commits 11
- 12. BRANCHES INHERITANCE /1.1 /1 /2.0 /1.0 /2 12
- 13. BUILDING FROM BRANCH /1 1.0 1.1 1.2 13
- 14. EXISTING VERSION NUMBERING APPROACH 1.2.3 [major].[minor].[build] ARCHITECTURE CONCEPTS PORTING ITERATIONS BUILD MARKETING 14
- 15. SIMILAR IDEAS 1. Version control for multiple agile teams: http://www.infoq.com/articles/agile-version-control 2. Configuration management patterns: http://www.cmcrossroads.com/bradapp/acme/branching/ 15
- 16. SIMPLEST SCENARIO 16 «2 days for release »
- 17. SIMPLEST SCENARIO After several subsequent commits developers want to build application Why? 1. It implements functional requirements (bugs/features) or performance requirements 2. Build is accessible by the end user: Building standalone application Deployment of web-application Gathering metrics and statistics (integration build) 17
- 18. SIMPLEST SCENARIO Then there is need to make a release Why? Release is a special type of a build But it has specific features: 1. Full implementation of requirements set 2. Quality 3. Usability 18
- 19. SIMPLEST SCENARIO SIMPLEST SCENARIO IS… …THE CASE WHEN ALL THESE STEPS DOES NOT REQUIRE TOO MUCH EFFORT «2 DAYS FOR RELEASE» 19
- 20. SIMPLEST SCENARIO release ! /trunk 1 ? 2 ? 3 ? 1.0 ? 1.1 ? 1.2 ? 20
- 21. MORE COMPLEX EXAMPLE 21 Extending the scope
- 22. IMAGINE … YOU NEED TO STABILIZE YOUR RELEASE and PROVIDE SIMULTANEOUS DEVELOPMENT OF ANOTHER APPLICATION VERSION 22
- 23. BRANCHING FOR RELEASE release merge ! ! /trunk 1 ? 2 ? 3 ? 2.0 ? 2.1 ? 2.2 ? 2.3 ? /1.x 23 1.0 ? 1.1 ? 1.2 ?
- 24. BRANCHING FOR RELEASE DID YOU NOTICE? INCONSISTENCY IN VERSIONS NUMBERING! IT MAKES SENSE TO SEPARATE DEVELOPMENT IN TRUNK AND RELEASE STABILIZATION 24
- 25. BRANCHING FOR RELEASE /trunk 1 ? 2 ? 3 ? 4 ? 5 ? 6 ? 7 ? 8 ? /1.x /2.x 1.0 ? 1.1 ? 1.2 ? 2.0 ? 2.1 ? 25
- 26. EXAMPLE EVEN MORE COMPLEX 26 Parallel branching
- 27. BRANCHING FOR RELEASE YOU WILL NEED TO BE ABLE TO GO TO THE RELEASE STABILIZATION ANYTIME and DO NOT INTERRUPT ANY OTHER DEVELOPMENT OR RELEASE STABILIZATION 27
- 28. BRANCHING FOR RELEASE /2.x 2.0 ? 2.1 ? /trunk 1 ? 2 ? 3 ? 4 ? 5 ? 6 ? 1.3 ? 2.2 ? 0.1 0.2 0.3 0.4 0.5 0.6 /1.x 1.0 ? 1.1 ? 1.2 ? 28
- 29. BRANCH TYPES It’s time to think about branch types! ? 29
- 30. BRANCH TYPES release branch /2.x x.x 2.0 ? 2.1 ? /trunk x.1 1 ? x.2 2 ? 3 ? x.3 4 ? x.4 5 x.5 ? 6 x.6 ? 1.3 x.7 ? 2.2 x.8 ? no type (it’s just trunk) release branch /1.x 1.0 ? 1.1 ? 1.2 ? 30
- 31. EXAMPLE OF THE CASE, WHEN BRANCHES BEGIN TO GROW BY THEMSELVES. 31
- 32. BRANCH TYPES incompatible changes /2.x 2.0 ? 2.1 ? cannot merge /trunk x.1 1 ? x.2 2 ? 3 ? x.3 4 ? x.4 5 x.5 ? 6 x.6 ? 1.3 x.7 ? 2.2 x.8 ? /1.x 32 1.0 ? 1.1 ? 1.2 ?
- 33. BRANCH TYPES Incompatible changes means: changes cannot be easily merged to the parent branch Example: deep refactoring (files hierarchy changes) serious architecture/application structure modification rewriting application or its part from scratch 33
- 34. BRANCH TYPES release branch /2.x /0.2.x 2.0 ? 2.1 ? 0.x.x 0.2.0 0.2.1 /trunk x.1 1 ? x.2 2 ? 3 ? x.3 4 ? x.4 1.3 x.5 ? cannot merge 0.x.1 0.x.2 0.x.3 0.x.4 0.x.5 release branch /1.x /1.x.x /? /0.1.x 1.0 ? 1.1 ? 1.2 ? support 34 0.1.0 0.1.1 0.1.2 branch
- 35. BRANCH TYPES /0.2.x /0.3.x /trunk /1.0.x /0.1.x /1.x.x release branch 35 support branch
- 36. SUPPORT VS RELEASE BRANCH Support branch Release branch Does not allow merge Allows merge with parent with parent branch branch Exists forever Exists only until stable version is released Child branches are Child branches are not allowed allowed Cannot have another support branch as child Deprecates merging with 36 child branch
- 37. BRANCH TYPES /trunk x.0 x.2 x.4 x.6 x.8 x.11 x.1 1 ? x.3 x.5 x.7 x.9 x.10 experimental branch 37
- 38. EXPERIMENTAL VS RELEASE BRANCH Release branch Experimental branch Does not allow child Allows any number of branches child branches Uses strict branch name. Name is not restricted at Example: 1.0.x all. Example: new_eng_test Uses own scope of builds Shares scope of builds numbering numbering between all relative branches Recommended merging No recommended approach: after each merging approach 38 build/release
- 39. CODEBASE INHERITANCE /0.2.x 0.x.x /trunk /2.x.x /0.1.x /1.x.x latest development 39
- 40. CODEBASE INHERITANCE Latest development should reside in trunk 40
- 41. CODEBASE INHERITANCE /3.x.x 1.x.x 2.x.x 3.x.x 4.x.x /trunk /2.x.x /1.x.x 41
- 42. TYPES OF BUILDS builds pre-alpha alpha (A) beta (B) (PA) releases alpha beta release release release candidate stable (ST) 42 (AR) (BR) (RC)
- 43. SCM IN ACTION 1.x.x 2.x.x /trunk PA 1.x.0 1.x.3 2.x.0 A 1.x.1 1.x.4 2.x.1 builds B 1.x.2 1.x.5 2.x.2 /1.x.x AR 1.0.0 BR 1.0.1 RC 1.0.2 1.0.3 releases ST 1.0.4 /1.0.x 43
- 44. SCRUM AND SCM /trunk PA/A 1.x.0 1.x.1 1.x.2 1.x.3 1.0.0 1.0.1 demo AR/BR user stories /1.0.x sprint backlog 44
- 45. SOURCE CODE REPOSITORY DIRECTORIES HIERARCHY 45
- 47. DIRECTORIES HIERARCHY TAGS 47
- 49. 1.x.x 2.x.x trunk PA 1.x.0 1.x.3 2.x.0 A 1.x.1 1.x.4 2.x.1 /tags/builds B 1.x.2 1.x.5 2.x.2 /branches/maintenance/versions/1.x.x AR 1.0.0 BR 1.0.1 RC 1.0.2 1.0.3 /tags/releases ST 1.0.4 /branches/releases/1.0.x Номера 1 12 39 52 73 79 93 112 126 139 140 155 170 193 201 215 230 ревизий 49
- 50. Afterword AFTERWORD 50
- 51. 51 Thank you for attention!
- 52. USEFUL LINKS 1. http://www.infoq.com/articles/agile-version-control - agile version control 2. http://svnbook.red-bean.com/ - official subversion reference/book “Version Control with Subversion” 3. http://www.ericsink.com/ - one of the best blogs about version control 4. http://www.versioncontrolblog.com/ - another great blog about version control 5. http://better-scm.berlios.de/comparison/comparison.html - VCS comparison table 6. http://www.cmcrossroads.com/ - biggest resource about SCM 7. http://www.infoq.com/news/2009/03/Continuous-Deployment - about continuous deployment 52
Notes de l'éditeur
- Итак, начнем с объемного вступления с большим количеством предварительных замечаний и оговорок.
- 1. Сразу нужно сделать акцент на том, почему же всё таки agileconfiguration management. Кто-то говорит об:ИтеративностиИнкрементальностиАдаптивности А я говорю о постоянно изменяющемся scope (если точнее, то постоянно растущем). Это поможет сделать примеры более похожими на реальную жизнь, а следовательно – более наглядными. И выявить противоречия, которые возникают при росте этого самого scope. Причем, мы побываем в неизведанном и узнаем…2. … как рост scope влияет на нумерацию версий приложений. В предыдущих тренингах мы уже оставили некоторые вопросы открытыми. Было обещано, что они будут решены в последнем тренинге серии, т.е. сегодня.
- Показать, как можно интегрировать практики конфигурационного менеджмента и agile-методологии путем введения дополнительной формализации при нумерации версий. Помните первую, вводную тему про экстремальное программирование, там где курица и яйцо?Продолжая аналогию, можно сказать, что номер версии – это днк проекта. Цель - этоСвязьС одной стороны - agile + SCMС другой стороны – SCM tools Эта магическая картинка очень важна для иллюстрации того, о чем мы общались, будем общаться и зачем это всё нужно.Я тут упомянул о практиках конфигурационного менеджмента. О них мы уже общались: vs, build management, ci. Сегодня о двух оставшихся лепестках – нумерации и релиз менеджменте. ПодходAgile SCM интегрирует всё это вместе. И наиболее полно раскрывает вопрос того, о чем же нам на самом деле говорит номер версии.
- Повествование – от простого к сложному. Поagile-ному: всё – эксперимент, всё – гибко. В том числе нумерация версий. Бритва Оккама
- Намеренно были выбраны ужасные и утрированные примеры того, чтобы показать то, как не должно быть. Основная цель этих «ужасных» примеров – это выявление противоречий.Как противоречия устраняются – узнаете по ходу, в нужное время.Примеры из реальной жизни мы уже рассматривали и оставили некоторые вопросы открытыми. Вот как раз с помощью устранения противоречий мы эти вопросы и закроем.
- Для иллюстрации эволюции ПО используются диаграммы потока разработки. Вы можете задавать себе вопрос: «Что такое диграммы потока?» По англ. это streamline. (может быть вы сделаете перевод лучше).Эти диграммы вы могли видеть в совершенно разнообразных местах, включая книгу version control with subversion. Диаграммы потоков могут быть изображены так, …
- … вот так
- так
- И вот так.Для затравки я вставлял в предыдущую презентацию изображение с диаграммы потока, описывающей процесс непрерывной интеграции. Это очень хороший пример того, как будут иллюстрироваться выкладки. Но не пугайтесь, вы не встретите здесь таких огромных диаграмм на А3. У powerpoint, к счастью, есть куча других визуальных возможностей. Опрос: кто пытался самостоятельно, после тренинга вникнуть в то, что там изображено?
- Прошу заметить, что на диаграммах потока разработки коммиты никак не изображены. Коммитов на диаграммах нет.Всё есть, даже директории. А коммитов – нет!
- Стрелками изображены ветки. Ветки разной толщины, разных типов. И еще одна особенность – ветки наследуются. Помните как создать ветку в репозиторииsvn? Правильно, командой svn copy. В английском языке есть замечательное слово codebase. Я его перевожу как «база исходного кода». Так вот, при наследовании веток наследуется не только номер версии, но и эта сама база исходного кода.
- На диаграммах потока вы столкнетесь с изображением сборок в виде прямоугольников. Пунктирная стрелка указывает своим началом на место, из которого сборка выполняется. Это ветки в репозитории исходного кода.
- И наверняка вы помните о том, из чего же состоит обычный номер версии. Из мажорной, минорной и версии сборки. Номер сборки – это номер сборкиМинорная версия указывает на номер итерацииМажорная версия может использоваться в нескольких целях. Это или обозначение кардинального изменения архитектуры, или…… концепции приложения… это портированная версия… обозначение полного жизненного цикла проекта от инициации до ретроспективы и завершения… или присваивание нового номера версии в связи с маркетинговыми целями. Это чудо, что windows 7 называется именно так!
- Есть очень похожий подход, описанный в одной из статей на сайтеInfoQ, называется agile version control. То, о чем я буду рассказывать, является логическим продолжением этой статьи (на самом деле, идею лежащую в основе названия данного подхода я тоже позаимствовал), а также идей, положенных в основу шаблонов конфигурационного менеджмента. Использовать вторую ссылку рекомендую только маньякам – тем, кто уж досконально хочет разобраться в вопросах конфигурационного менеджмента.
- Цели – тестирование результата разработчиком или еще кем-то
- Одна, вторая, третья сборка, а затем – релиз. Релиз – это та же сборка, но с гарантией качества.При данномscope неизвестно, будет ли разрабатываться приложение дальше.
- Цель – релиз с минимальными усилиями. Соответствие треугольникуscope-cost-resources. Это значит, что количество действий, производимых с системой контроля версий, инструментами сборки, настройкой зависимостей минимально.
- Иногда не все так просто. Нужно расширить scope.
- На диаграмме изображено всё то же самое, но создается отдельная ветка для релиза и сливается с основным направлением разработки. Пример намеренно утрирован – в реальной жизни наверняка никто нумеровать версии так не будет. Поэтому никто к явному противоречию и не придет, а если и придет, то решать эти противоречия не будет.
- И что же мы заметили?Непоследовательность в нумерации: сначала 1, 2, 3, затем 1.1, 1.2, 1.3, затем 2.3И как мы это будем решать? ваши предложенияМое предложение - нужно разделить разработку trunk/release
- Теперь каждый релиз – в отдельной ветке. Тогда будет соблюдаться последовательность нумерации
- У нас всё гибко!
- Следующее противоречие – номер версии 1.3 и 2.2.Опять непоследовательность!После слияния ветки стабилизации 1.х в trunk базы исходного кода обоих веток объединяются. Таким образом, может возникнуть путаница по поводу того, какие номера версий назначать сборкам после слияния. Продолжать нумеровать так же, как предыдущие сборки в trunk? Или следовать продолжению нумерации, принятой в ветке стабилизации? Если базы исходного кода двух веток объединились, то оба подхода будут равноправными, ведь так? Или, может быть, не совсем? Можно решить этот вопрос введением соответствия между именованием, принятым до перового слияния и двухсоставными номерами версий. Но этого, наверное, все таки, мало.
- Сейчас наступил именно тот момент, когда нужно подумать о типах ветокТема управления ветками и слияниями выходит за рамки серии тренингов. Единственный шаг, который мы в этом направлении делаем – это классификация веток и определение правил работы с ними.
- Если мы будем разграничивать типы веток, то они уже будут не равноправными. Ветки, в которых происходила стабилизация, будут называться ветками релиза.У trunk не будет типа (это просто trunk).Но тем не менее, на этом этапе уже нужно дифференцировать подходы к именованию сборок в зависимости от ветки, которая является базой исходного кода для такой сборки. Если мы принимаем соглашение о двухсоставности номера версии, тогда воображаемый номер версии ветки trunk (следуя логике именования самих веток) будет иметь вид ‘x.x’Так как не имеет смысла говорить о номере итерации для trunk, то номер минорной версии для сборок из trunk будет оставаться всегда одним и тем же – ‘x’.Следовательно, номера сборок будут следующими: x.1, x.2, … х.8Опрос: используете ли вы ветки для релизов?Ветки багфиксов
- Существует вероятность, что на каком-то этапе возникнет невозможность слияния в родительскую ветку изменений, выполненных в дочерней ветке. Такие изменения оказываются несовместимыми. Опрос: когда вы создаете ветки поддержки?
- Несовместимость может возникнуть по нескольким причинамГлубокий рефакторингСерьезные архитектурные или структурные изменения(и, самая распространенная причина) Переписывание приложения с нуля. В этом случае часто удобней всего создать новый репозиторий, но решение об этом может зависеть от множества факторов, в частности, удобства администрирования.
- Как в это в итоге повлияет на иерархию веток?Несовместимые изменения должны быть выделены в отдельную ветку, на которую накладываются ограничения при проведении слияний. Если точнее, то слияния как С родительской веткой, так и В родительскую ветку становятся невозможны.Какому подходу к нумерации следовать при назначении номера версии для этой ветки? Ведь это ветка отличного типа как от trunk, так и от ветки релиза. Кроме того, если мы определяем невозможность слияний этой ветки с другими, то допустимым шагом может быть создание совершенно отдельного репозитория для поддержки этой версии. Как решение, мы присваиваем новый номер мажорной версии для ветки, в которой содержатся несовместимые изменения. Такая ветка будет называться веткой поддержки и ей будет присвоен номер версии 1.х.х.Тогда, по аналогии, воображаемый номер версии ветки trunk будет иметь вид 0.х.х. Так как номер версии родительской ветки должен наследоваться при выполнении сборок, соответствующие номера версий также поменяются. Так как наследуются не только номера версий сборок, но и дочерних веток, соответствующие номера версий также изменятся (0.1.х, 0.2.х). И, соответственно, изменятся номера версий сборок, для веток релиза (0.1.0, 0.1.1, …)
- Как уже было сказано, появляется еще один тип ветки – ветка поддержки, которая на диаграммах потока разработки будет изображаться другим цветом.
- Более детально сравним два типа веток: ветки релиза и ветки поддержкиДля веток релизадопускается слияние с родительской веткой, в то время как для ветки поддержки слияние не допускаетсяВетка поддержки существует всегда, в то время как ветка релиза существует только до тех пор, пока не выпущена стабильная версия релиза.В ветке релизане разрешается создавать дочерние ветки, тогда как создание дочерних веток разрешено для веток поддержки.Кроме того, веткам поддержкизапрещено иметь дочерние ветки поддержки. И не рекомендуются слияния с дочерними ветками (кроме экспериментальных, что такое экспериментальные ветки – чуть позже).
- Еще один тип веток – экспериментальные. На экспериментальные ветки не накладывается практически никаких ограничений: ни на количество дочерних веток (1), ни на именование самих веток, ни на слияния. Два единственных ограничения – это:(2) Номер сборок, выполняющихся из экспериментальной ветки. Должна соблюдаться сквозная нумерация, принятая для родительской ветки.Время создания. Экспериментальные ветки могут быть дочерними только для веток поддержки (и НЕ для веток релиза)Вот это тот случай, когда должны вступать в бой возможности DVCS. Причем, в этом месте у людей начинает образовываться полная каша в голове. Если вы ничего не поняли, не переживайте!
- Краткое сравнение:ПотомкиСвободное именование Область значенийСлиянияОпрос: какие типы веток вы используете?
- Еще одно противоречие – это преемственность разработки. При правильной организации преемственности самые последние изменения должны содержаться в trunk. В то же время до сих пор мы видели, что именно несовместимые изменения выделяются в отдельную ветку и, соответственно, последние изменения будут содержаться именно там – в ветке 1.х.х, а потом и в ветке 2.х.х, ответвление которой, вполне возможно, произойдет чуть позже после выявления очередных несовместимых изменений.Проблема заключается в том, что… [следующий слайд]
- … [no comments]
- … вот как показано здесьДля решения противоречия о преемственности, нужно ввести дополнительные соглашения о наследовании базы исходного кода. Такие соглашения подразумевают то, что при выявлении несовместимых изменений, они остаются в trunk, а база исходного кода, соответствующая моменту времени ДО применения несовместимых изменений выделяется в отдельную ветку – ветку поддержки. Таким образом, trunk будет содержать изменения всех мажорных версий: сначала 1.х.х, потом 2.х.х итд. Причем, эти номера версий будут мнимыми. Trunk остается trunk’ом, но номера версий сборок, выполненных из транка, меняются. Отрезкам в trunk’e, имеющим разные номера мнимых версий будут соответствовать диапазон изменений:От начала разработки до момента ответвления ветки поддержкиОт момента ответвления предыдущей ветки поддержки до момента ответвления следующей ветки поддержки (отрезок от момента ответвления ветки 1.х.х до момента ответвления 2.х.х)Опрос: как вы проводите слияния?
- Помните какая разница между сборками и релизами?Релиз – это всего лишь особый тип сборок, характеризующийсяПолной реализацией набора функциональных требованийКачеством (т.е. отсутствием ошибок, не позволяющим в наиболее полной мере воспользоваться возможностями приложения)И, как следствие первых двух пунктов, релиз характеризуется доступностью к использованиюПеред тем как перейти к общей схеме организации веток и изложению подхода к именованию версий, нужно упомянуть о классификации сборок и релизов. Классификация основана на том, кто является конечным пользователем сборки или релиза. Конечными пользователями могут быть: сами разработчики (PA), тестировщики (A, AR), заказчик или целевые пользователи (B, BR, RC, ST). Также есть тип релиза, предусматривающий вызревание релиза в отведенный для этого отрезок времени (RC, ~1 месяц).Такая подробная классификация определяет зрелость (maturity) артефактов, получаемых в результате разработкина разных стадиях.А следовательно, определяет также и качество этих артефактов.
- Вот мы и пришли к наиболее общей схеме, учитывающей практически все тонкости подхода к именованию версий выпускаемого ПО.Здесь, на диаграмме можно выделить сборки двух основных типов – просто сборки (builds) и релизы. Которые в свою очередь также делятся на подтипы. Сборки делятся на PA, A, B. Это соответствует тому, кто является пользователем сборки: разработчик, тестировщик или конечныйпользователь. Примерно такая же классификация релизов: AR, BR, RC, ST. Для AR точно так же конечные пользователи - тестировщики. Для BR – Для выпуска стабильной версии должно пройти продолжительное время с целью «вызревания» релиз-кандидата до стабильной версии. Для этого вводится понятие релиз кандидат (RC). Время вызревания может определяться конкретно для каждого проекта в зависимости от специфики. После этого релиз становится стабильным. По-умолчанию в trunk’e, основном направлении разработкисодержится мажорная версия номер 1. Номера версий сборок, выполненных из транка, будут соответствующими: 1.х.0, 1.х.1, 1.х.2. Причем сборки сразу дифференцируются по типам: PA, A, B. На очередность типов сборок не накладываются ограничения в отличии от очередности типов релизов. Они могут выполняться в любом порядке, единственно, с учетом того, кто является конечным пользователем: разработчик, тестировщик или целевой пользователь. При возникновении несовместимости (изображено треугольничком) направление разработки, соответствующее моменту времени до применения несовместимых изменений выделяется в отдельную ветку 1.х.х. Сквозная нумерация будет сохранена для номеров версий сборок, выполненных из ветки 1.х.х: 1.х.2 сборка была выполнена из транка, значит следующими номерами сборок, выполненных из ветки 1.х.х будут сборки с номерами 1.х.3, 1.х.4.После ответвления ветки поддержки 1.х.х в транке будет содержаться вторая мажорная версия приложения. Соответственно, номера сборок, выполненных из транка, будут следующими: 2.х.0, 2.х.1При необходимости выпустить релиз первой мажорной версии, создается отдельная ветка с унаследованным номером мажорной версии (1) и новым номером итерации (минорная версия). В нашем случае будет создана ветка 1.0.х.Параллельно стабилизации релиза разработка может продолжаться и в других ветках. Соответственно, сборки из других веток тоже могут выполняться. Примеры: сборка 1.х.5, А также сборка 2.х.2.Номера версий релизов, выполненных из ветки 1.0.х являются полноценными – без всяких иксов. От 1.0.0 до 1.0.4. Причем релиз 1.0.4 является стабильным. После выпуска этого релиза, ветку 1.0.х можно удалять. Но нужно учесть, что для выпуска стабильной версии должно пройти продолжительное время с целью «вызревания» релиз-кандидата до стабильной версии. Время вызревания может определяться конкретно для каждого проекта в зависимости от специфики.
- Можно проиллюстрировать применение описанного подхода для разработки согласноSCRUM-методологии. При наличии набора user stories реализации отдельной story будут соответствовать отдельные сборки (user story depositбудет соответствовать сборка 1.х.1, user story migration toolбудет соответствовать сборка 1.х.2, итд). Затем, при окончании итерации и необходимости в выпуске демо-приложения при реализации всего sprint backlog’a создается стабилизационная ветка релиза. Сборки, выполненные из этой ветки будут соответствовать полноценным релизам приложения, демонстрируемых заказчику как результат спринта.
- Весь описанный процесс фиксируется очень особым образом – созданием директорий в репозитории. Причем директории именуются также совершенно особым образом.
- Пример иерархии директорий:Помимо стандартных trunk, tags, branches…… есть еще builds, releases… maintenance, experimental, …
- Директория тегов структурируется в соответствии с классификацией сборок и релизов.
- Каждой ветке (и не только ветке) соответствует директория в репозитории.Пунктирной линией показано направление наследования базы исходного кода, начинающейся в trunk
- В EPAM есть continuous engineering services – команда билд-инженеров и мейнтейнеров, которые с радостью готовы вам помочь в поддержке процессов сборки и развертывания вашего проекта. Так же они готовы предоставить отдельный репозиторий для ваших нужд и заботиться о его содержимом.Но большинство команд всё таки используют ресурсы заказчика или свои собственные ресурсы даже несмотря на наличие такого замечательного внутреннего сервиса. Независимо от того, нужно вам поддерживать инфраструктуру для сборок и релизов вашего приложения, основные идеи этого процесса нужно знать. И сегодня я рассказал о довольно глубоких тонкостях, которые будут способствовать более глубокому пониманию того, что же такое конфигурационный менеджмент и как он влияет на весь ЖЦ ПО. Влияет он очень просто – номера версий приложения используются повсеместно. И знание того, как же правильно номера версий назначать за плечами носить не придется. Кроме всего прочего, независимо от того, используете ли вы CES, усвоенные знания вы сможете применять при повседневной работе с svn.По поводу революционности идей.