Email
Like
Liked ×
Save
Private Content
Embed
Loading embed code…
We have emailed the verification/download link to "".
Login to your email and click the link to download the file directly.

To request the link at a different email address, update it here. Close
Validation messages. Success message. Fail message.

Check your bulk/spam folders if you can't find our mail.
Loading

+ Follow

04 - Agile Software Configuration Management

by Sergey Shmarkatyuk

753 views

Accessibility

View text version

Upload Details

Uploaded via SlideShare as Microsoft PowerPoint

Usage Rights

File a copyright complaint

Statistics

Likes: 1
Downloads: 29
Comments: 0
Embed Views: 0
Views on SlideShare: 753
Total Views: 753

Итак, начнем с объемного вступления с большим количеством предварительных замечаний и оговорок.
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.По поводу революционности идей.

1 Like

iamdanielkim 1 week ago

04 - Agile Software Configuration Management Presentation Transcript

AGILE SOFTWARE CONFIGURATION MANAGEMENT
INTRODUCTION2 General conventions and ideas
3
GOALCONNECTION BETWEEN:1. AGILE-METHODOLOGIES AND CONFIGURATION MANAGEMENT PRACTICES2. TOOLS UTILIZED BY SOFTWARE CONFIGURATION MANAGEMENT PRACTICES Version control Build & Versions deployment numbering managementAgile SCM 4 Release Continuous management integration
NARRATION FROM SIMPLE TO COMPLEX… 5
NARRATION …WITH SIMULTANEOUS ELIMINATION OF EMERGING CONTRADICTIONS 6
REPRESENTATION STREAMLINE DIAGRAMS 7
REPRESENTATION STREAMLINE DIAGRAMS 8
REPRESENTATION STREAMLINE DIAGRAMS 9
REPRESENTATION STREAMLINE DIAGRAMS 10
REPRESENTATION STREAMLINE DIAGRAMS branches releases builds tags merges directories commits 11
BRANCHES INHERITANCE /1.1 /1 /2.0 /1.0 /2 12
BUILDING FROM BRANCH /1 1.0 1.1 1.2 13
EXISTING VERSIONNUMBERING APPROACH 1.2.3 [major].[minor].[build] ARCHITECTURE CONCEPTS PORTING ITERATIONS BUILD MARKETING 14
SIMILAR IDEAS1. Version control for multiple agile teams:http://www.infoq.com/articles/agile-version-control2. Configuration management patterns:http://www.cmcrossroads.com/bradapp/acme/branching/ 15
SIMPLEST SCENARIO16 «2 days for release »
SIMPLEST SCENARIO After several subsequent commits developers want to build application Why?1. It implements functional requirements (bugs/features) or performance requirements2. Build is accessible by the end user:  Building standalone application  Deployment of web-application  Gathering metrics and statistics (integration build) 17
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
SIMPLEST SCENARIO SIMPLEST SCENARIO IS… …THE CASE WHEN ALL THESE STEPS DOES NOT REQUIRE TOO MUCH EFFORT «2 DAYS FOR RELEASE» 19
SIMPLEST SCENARIO release ! /trunk 1 ? 2 ? 3 ? 1.0 ? 1.1 ? 1.2 ? 20
MORE COMPLEX EXAMPLE21 Extending the scope
IMAGINE … YOU NEED TO STABILIZE YOUR RELEASE andPROVIDE SIMULTANEOUS DEVELOPMENT OF ANOTHER APPLICATION VERSION 22
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 ?
BRANCHING FOR RELEASE DID YOU NOTICE? INCONSISTENCY IN VERSIONS NUMBERING!IT MAKES SENSE TO SEPARATE DEVELOPMENT IN TRUNK AND RELEASE STABILIZATION 24
BRANCHING FOR RELEASE /trunk1? 2 ? 3 ? 4 ? 5 ? 6 ? 7 ? 8 ? /1.x /2.x 1.0 ? 1.1 ? 1.2 ? 2.0 ? 2.1 ? 25
EXAMPLE EVEN MORE COMPLEX26 Parallel branching
BRANCHING FOR RELEASEYOU WILL NEED TO BE ABLE TO GO TO THE RELEASE STABILIZATION ANYTIME andDO NOT INTERRUPT ANY OTHER DEVELOPMENT OR RELEASE STABILIZATION 27
BRANCHING FOR RELEASE /2.x 2.0 ? 2.1 ? /trunk1? 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
BRANCH TYPESIt’s time to think about branch types! ? 29
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
EXAMPLE OF THE CASE, WHEN BRANCHES BEGIN TO GROW BY THEMSELVES.31
BRANCH TYPES incompatible changes /2.x 2.0 ? 2.1 ? cannot merge /trunkx.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 ?
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
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 merge0.x.1 0.x.2 0.x.3 0.x.4 0.x.5release 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
BRANCH TYPES /0.2.x /0.3.x /trunk /1.0.x /0.1.x /1.x.x release branch 35 support branch
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
BRANCH TYPES /trunkx.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
EXPERIMENTAL VS RELEASEBRANCH 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
CODEBASE INHERITANCE /0.2.x 0.x.x /trunk /2.x.x /0.1.x /1.x.x latest development 39
CODEBASE INHERITANCELatest development should reside in trunk 40
CODEBASE INHERITANCE /3.x.x1.x.x 2.x.x 3.x.x 4.x.x /trunk /2.x.x /1.x.x 41
TYPES OF BUILDS builds pre-alpha alpha (A) beta (B) (PA) releases alpha beta release release release candidate stable (ST) 42 (AR) (BR) (RC)
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
SCRUM AND SCM/trunkPA/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
SOURCE CODE REPOSITORY DIRECTORIES HIERARCHY45
DIRECTORIES HIERARCHYPROJECT 46
DIRECTORIES HIERARCHYTAGS 47
DIRECTORIES HIERARCHYSUPPORT BRANCHES 48
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
Afterword AFTERWORD50
51Thank you for attention!
USEFUL LINKS1. http://www.infoq.com/articles/agile-version-control - agile version control2. 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 control4. http://www.versioncontrolblog.com/ - another great blog about version control5. http://better-scm.berlios.de/comparison/comparison.html - VCS comparison table6. http://www.cmcrossroads.com/ - biggest resource about SCM7. http://www.infoq.com/news/2009/03/Continuous-Deployment - about continuous deployment 52

04 - Agile Software Configuration Management

by Sergey Shmarkatyuk

Accessibility

Categories

Upload Details

Usage Rights

Statistics

04 - Agile Software Configuration Management Presentation Transcript