2. TITLE
SOFTWARE CONFIGURATION
MANAGEMENT TRAININGS SERIES
2
3. FORMAT
Training Seminar Webinar
Master-
Workshop Conference
class
Language Adaptational
Mindstorm
lesson training 3
4. FORMAT
Training Seminar Webinar
Master-
Workshop Conference
class
Language Adaptational
Mindstorm
lesson training 4
5. FORMAT Presentations
Training Seminar Demos Webinar
Master-Homework
Workshop Conference
class
Pre-testing
Language Adaptational
Mindstorm
lessonPost-testing training 5
(evaluation)
10. INTRODUCTION TO SOFTWARE
CONFIGURATION MANAGEMENT
Extreme programming and configuration
management: chicken-and-egg
Evolution of software product.
Extreme programming (XP) practices.
Configuration management practices.
Comparison of XP and SCM practices.
Software engineering models.
Using CMMI model as an example of SCM importance.
SCM as the background for effective software development.
What does version number tell us?
What is version? Why do we need it?
Work products (artifacts) versioning: artifact properties
Version number elements: inheritance and composition
11
Deriving artifact properties using version number.
11. CONTENTS
2. INTRODUCTION TO VERSION
CONTROL
12
12. INTRODUCTION TO VERSION CONTROL
What is Version Control (VC)?
History and evolution of Version Control: in brief.
Two main approaches to versioning your source code.
Main instruments and tools: SVN, CVS, VSS, Git.
Distributed version control (DVC) and Centralized
version control (CVC): advantages, disadvantages and
differences.
Short domain vocabulary: words specific to version
control systems usage and what do they mean.
What should not be confused with version control: asset
management, digital libraries, dependency management.
13
13. CONTENTS
3. BUILD AND DEPLOYMENT
MANAGEMENT
14
14. BUILD AND DEPLOYMENT MANAGEMENT
What is build?
Why do we need to build?
Build types.
Tools and their specifics.
Building for different platforms.
Build vs deployment.
Optimized approach to manual building.
Builds numbering.
Example of web-application build process 15
16. CONTINUOUS INTEGRATION
Why do we need continuous integration?
Prerequisites for continuous integration
process.
General workflow.
How does continuous integration affect our
development process?
Tools and their features.
When CI is not effective?
We have “true CI”. What next?
CI and CMMI product integration process area 17
28. ABOUT YOU
• NAME, POSITION, UNIT
• DO YOU KNOW WHAT SCM IS?
• WHY DO YOU WANT TO KNOW WHAT IT IS OR LEARN
MORE?
• IS THERE SOMETHING SPECIFIC YOU WOULD LIKE TO
KNOW OR TALK ABOUT?
29
Серия тренингов, посвященная конфигурационному менеджменту
Обычно я провожу обычные тренинги, воркшопы, выступаю на конференциях. Привык к глазам, смотрящим на меня. Формат вебинаров акладывает некоторые ограничения: нужно соблюдать динамику, знать о чем рассказывать, сложно следить за реакцией присутствующих. Вебинары я провожу не так часто, поэтому заранее прошу меня извинить если будут какие-то недоразумения.
Серия тренингов подготовлена, так сказать, «на экспорт». У себя в офисе мне, кроме всего прочего, посчастливилось проводить воркшопы на английском языке, на эту же тему – тему конфигурационного менеджмента. Это была инициатива со стороны преподавателей английского киевского офиса – проводить занятия на английском языке на техническую тему. Поэтому я делаю материалы сразу адаптированными для нескольких языков.
РазработчикиРезультат именно деятельности разработчиков подлежит контролю конфигурации и контролю изменений. Я не уверен насчет того, может ли считаться разработчик разработчиком (имеется в виду миддл) без знания хотя бы простейших систем контроля версий. Кроме того, что разработчики сохраняют результаты своей работы в репозитории исходного кода, они еще и …… мерджат (проводят слияния) изменения, …… выполняют сборки… пишут юнит-тестыТестировщикиТестеры должны хорошо понимать, что же они тестируют. Четко должна прослеживаться взаимосвязь между требованиями и результатами разработки. Для этого используются номера версий – как основной способ описать конфигурациюи связать требования к продукту с результатом разработки этого продукта.Зрелость продукта напрямую связана с качеством. Alpha, beta, release candidate, итд. И каждый релиз – это тоже еще одна конфигурация.Инженеры поддержки (или, в простонародии, саппортеры). Часто такие люди занимаются релиз-менеджментом. Релиз = конфигурацияИнженеры качества. Эти доблестные люди следят за качеством процессов. Одной из моделей, описывающей качество процессов, является CMMI. И в число процессных областей CMMI входит конфигурационный менеджмент. Откуда, собственно, название дисциплины и возникло.Для инженеров качества важно, чтобы процессы разработки были описаны и формализованы. А также то, чтобы процессами с радостью пользовались и следовали им. Радость невозможна без: понимания, простоты, эффективности, удобностиС этой точки зрений последний тренинг серии будет настоящей находкой для QA. Я постараюсь описать, как принципы Agile SCM применимы к требованиям CMMI и процессной области CM.Проектные менеджерыНаиболее общая схема построения платформы конфигурационного менеджмента вместе с пониманимем того, как это работает несколько упрощают планирование проектов и релизов. Одно дело – роль, которую вы выполняете на проекте, а другое – насколько вам вообще это интересно и нужно. Поэтому идеальной аудиторией для тренингов будут те, кто нашел что-то полезное для себя после участия в вебинаре «Agile SCM». «Agile SCM» - это самая вершина айсберга, общие идеи и принципы для построения целостной платформы конфигурационного менеджмента. Этот тренинг (Agile SCM) не был призван осветить все тонкости, в то время как серия тренингов направлена именно на это – максимально полное освещение тематики.
Тем не менее, очень специфичные вопросы в рассмотрение не войдут: управление зависимостями (рассмотрение этой темы невозможно без досконального понимания принципов конфигурационного менеджмента, о которых я буду рассказывать), интеграция баз данных (непаханное поле)На данный момент я ограничиваюсь 5-ю тренингами.
Первый тренинг, сегодняшний – вводный. Это основные идеи и концепции
Начну я с проблемы курицы и яйца. С одной стороны у нас – эксремальное программирование, а с другой – инструменты, которые мы используем. Продолжу я повествованием о том, что же таит в себе для нас номер версии?
Базой для всего конфигурационного менеджмента служит контроль версий. Конфигурационный менеджмента настолько тесно связан с контролем версий, что часто даже путают VC c SCM. Говорят “Put your source code under SCM”.Бррр… режет слух.
Одной из основных целей тренинга посвященного контролю версий – это сравнение централизованного и распределенного подходов. Многие считают, что это противоборствующие и непримиримые концепции. Это, к счастью, далеко не так. Для каждой из этих концепций существует специфическое применение и я об этом расскажу. Кроме того, я сделаю акцент на месте контроля версий среди всех остальных практик конфигурационного менеджмента.
Так сложилось, что вопросами сборок, развертывания и интеграции приложений занимаются обычно разработчики. Отдельная роль билд-менеджера выделяется редко. А если и выделяется, то всё равно такой человек занимается рядом смежных вещей. Хотя не буду утверждать наверняка, я ведь не знаю как дело обстоит у вас в проекте. Но в тренинге, посвященном управлению сборками и развертываниями я покажу, насколько обширная это, на самом деле, тема. Тонкостей достаточно таки много.
Мы рассмотрим основные понятия, а также продолжим тематику номеров версий и того, о чем же они нам говорят. 3.Основные рассматриваемые вопросы – это типы сборок и конфигурирование сборок. 9. Пример позволит выявить некоторые противоречия, решения которых нужно искать уже за рамками управления сборок. Таким образом, я также укажу на место билд менеджмента среди всех остальных практик конфигурационного менеджмента.
«О. будут рассказывать о continuous integration!»
Обычно о непрерывной интеграции рассказывают что-то общее, или демонстрируют работу инструментов указывая на то, как они помогают в разработке. Я об этом тоже говорю, но при этом копаю чуть глубже: …7. … мы затрагиваем тему того, как же инструменты непрерывной интеграции могут дальше развиваться для того, чтобы быть более интегрированными с остальными практиками конфигурационного менеджмента. Таким образом, я также укажу и на место continuous integration в конфигурационном менеджменте. 8. Кроме того, проводится связь с соответствующей процессной областью CMMI. Это показывает то, насколько важно использование непрерывной интеграции для зрелости процессов разработки.
Release management,version numbering
Release management,version numbering
Я буду часто повторяться. Это сделано намеренно. Если какая-то важная идея будет прозвучит всего один раз, очень многое впоследствии будет непонятым.
В качестве примеров я вам предлагаю живые демонстрации работы с файлами и тестовым проектом. Во время наших демонстраций я буду задавать некоторые вопросы, обращенные в будущее. Т.е. по ходу работы с проектом будут возникать ситуации, из которых мы не сможем найти удовлетворяющий нас выход. И мы будем пользоваться временными решениями, оставляя ответ на вопросы «на потом». В нужное время, уже обладая нужными нам знаниями мы на эти вопросы ответим. В самом последнем тренинге я буду пользоваться довольно абстрактными примерами, оперируя кучей допущений и предполагая, что вы уже знаете о чем идет речь.
Расписание довольно плотное: понедельник, среда, пятница (прямо как занятия танцами, курсы скорочтения или плавание)Время довольно удобное (11-00 – 12-30): заказчики еще не появляются в скайпах и не пишут письма. Как показали результаты исследований британских ученых, утро – самое удобное время для воспринятия информации. Шутка
Очень хотелось бы чтобы вы посетили каждый тренинг и выполнили все задания. Задания интересные и довольно тесно связаны с практическими вещами.
Последний момент, на котором я хочу сделать акцент. Серия тренингов более чем обычно сфокусирована на теоретических аспектах разработки ПО. Это означает то, что кроме практических аспектов конфигурационного менеджмента, рассматриваются также случаи «оторванных от реальности» идеальных случаев. Такие теоретические построения не обязательно означают то, что излагаемые идеи неприменимы на практике, а устанавливают приоритеты для совершенствования процессов разработки и расширения функциональности инструментов, которые при этом используются. Я подозреваю, что из-за большого количества теории будет возникать соблазн не слушать, пропустить что-то, вы можете подумать что и так знаете о чем идет речь. К примеру, вы пропустите один тренинг – и большая часть общей картины будет утеряна. Так как мы идем к наиболее глубокому пониманию области, где каждая составляющая важна, я рекомендую всё таки выделить время и силы для полноценного участия. И я недаром называю нашу серию занятий именно серией тренингов. Здесь важно активное ваше участие.