0
CONTINUOUS INTEGRATION
TRAINING GOALS  Show that there is no way present-day project could be successful without usage ofcontinuous integration p...
TRAINING PLAN1.   What is continuous integration?2.   Why do we need continuous integration?3.   Prerequisites for continu...
INTRODUCTION TO CONTINUOUS    INTEGRATION4   Basic ideas
WHAT IS CONTINUOUSINTEGRATION?                     5
WHAT IS CONTINUOUSINTEGRATION?•   Integration is when you make everything work together•   Continuous is when you make eve...
WHAT IS CONTINUOUSINTEGRATION?                Software               engineering                 practice      Another ste...
WHY DO WE NEED CONTINUOUSINTEGRATION? Martin    Fowler:… team integrate their work frequently,… leading to multiple integ...
PREREQUISITES FOR CONTINUOUSINTEGRATIONNot everything   you can continuously integrate                                    ...
PREREQUISITES FOR CONTINUOUSINTEGRATION               Single source                 code repo               (VCS system)  ...
GENERAL CI WORKFLOW                                    BuildCommitting                   (compilation, unit-  latest      ...
GENERAL CI WORKFLOW                changes                detected                                            build &     ...
GENERAL CI WORKFLOW          Check        modification                         Build                       application    ...
TOOLS14   Instruments for continuous integration and their     features
TOOLS CLASSIFICATIONCI toolsBuild management toolsUnit testing toolsInspection tools• Code coverage analysis• Static analy...
CI TOOLS              CruiseControl              CruiseControl.NET              CruiseControl.rb              JetBrain...
CI TOOLS                 CruiseControl                 CruiseControl.NET                 CruiseControl.rb              ...
CI TOOLS                 CruiseControl                 CruiseControl.NET                 CruiseControl.rb              ...
CI TOOLS                    CruiseControl                    CruiseControl.NET                    CruiseControl.rb     ...
CI TOOLS                     CruiseControl                     CruiseControl.NET                     CruiseControl.rb  ...
CI TOOLS                    CruiseControl                    CruiseControl.NET                    CruiseControl.rbTaggi...
CI TOOLS               CruiseControl               CruiseControl.NET               CruiseControl.rb           Distribut...
CI TOOLS                     CruiseControl                     CruiseControl.NET                     CruiseControl.rbFo...
CI TOOLS                 CruiseControl                 CruiseControl.NET                 CruiseControl.rb  CI tools wri...
CI TOOLS                     CruiseControl                     CruiseControl.NET                     CruiseControl.rbYe...
CI TOOLS Too many tools All are great All have the same principle But each has specific featuresDiagrams, metrics, rep...
CI TOOLS. ALM APPROACH               Requirements  Initiation   development &      Design                management   Test...
CI TOOLS. ALM APPROACH               Requirements  Initiation   development &                   Design                mana...
CI TOOLS. ALM APPROACH                  Requirements   Initiation     development &                   Design              ...
BUILD TOOLS                 Ant                 NAnt                 MSBuild                 Maven                 Ma...
BUILD TOOLS                       Ant                       NAnt                       MSBuild                       M...
BUILD TOOLS                       Ant                       NAnt                       MSBuild                       M...
BUILD TOOLS                       Ant                       NAnt                       MSBuild                       M...
BUILD TOOLS                      AntBuild management + dependencies management                       NAnt  for Java proj...
BUILD TOOLS                      Ant   Standard de facto for UNIX applications                     NAnt                 ...
BUILD TOOLS                       AntImplementation of build management tool in PHP                       NAnt          ...
BUILD TOOLS                        AntImplementation of build management tool in Ruby                       NAnt        ...
UNIT TESTING TOOLS                   Junit                   NUnit                   CppUnit                   PHPUnit...
INSPECTIONS TOOLS.TEST COVERAGE Cobertura Atlassian Clover jTest JCoverage CodeCover EMMA Parasoft Insure++ Ncover...
INSPECTIONS TOOLS.TEST COVERAGE Cobertura Atlassian Clover jTest JCoverage                      Java CodeCover EMMA...
INSPECTIONS TOOLS.STATIC ANALYSIS PMD FindBugs JLint FxCop Checkstyle ReSharper PHP_CodeSniffer Yasca             ...
INSPECTIONS TOOLS.COPY/PASTE DETECTORSCPD  (Copy paste detector)CheckstyleSimianJplagAtomiqClone diggerPBA         ...
DOCUMENTATION GENERATIONTOOLS  Doxygen    JavaDoc        NDoc        CppDoc        phpDocumentor    pyDoc  RDoc           ...
OTHER TOOLS    Source code     Dead code    metrics (loc)   detectors       Profiling       …                             ...
CI IN EPAM MICROSOFTTECHNOLOGIES DIVISIONProject     Project Product Primary   CCNET   Code Analysis    Unit        Test  ...
CI IN EPAM MICROSOFTTECHNOLOGIES DIVISIONProject           Project Product Primary   CCNET   Code Analysis   Unit        T...
MOST TYPICAL QUESTIONS    All the above-described info sounds cool. I  feel that it might be useful in my project. But I ...
ADVANCED CONTINUOUS     INTEGRATION48   More complex issues related to the continuous     integration
HOW DOES CI AFFECTDEVELOPMENT PROCESS? Commit   policy (mainlines are on the watch) Dont break the build rule (make loca...
“DON’T BREAK THE BUILD”RULE   Test code properly before    checking in   Avoid depending on a local    resource that is ...
“DON’T BREAK THE BUILD”OBSESSION   It is often impossible to    reproduce integration    problem without checking in.   ...
“DON’T BREAK THE BUILD”OBSESSION. SOLUTION Nightly builds instead of  builds „on commit‟ Team needs more strict and  les...
WHEN CI IS NOT EFFECTIVE? DVCS Experimental  development Small projects Interpreted languages without unit-tests When...
WE HAVE "TRUE CI".WHATS NEXT? Building  tags Separate builds having different maturity     levels                      ...
WE HAVE "TRUE CI".      WHAT’S NEXT?                 1.x.x                                              2.x.x/trunk PA    ...
WE HAVE "TRUE CI".   WHAT’S NEXT?                     1.x.x                                                               ...
WHAT NEXT? VERSIONSNUMBERING PATTERNS                  N.x.x.L pilot integrationintegration                  N.x.K.L devel...
59
CONCLUSION Thereis a lot of possibilities to make your continuous integration better:     Several integration streamline...
CONCLUSION CI  is another SCM tool (practice) Middle size project should definitely  have it. It is used mostly in agil...
AFTERWORD62
RECOMMENDED READING1. Continuous Integration: Improving Software Quality and   Reducing Risk by Paul M. Duvall, Steve Maty...
RECOMMENDED READING2. Continuous Delivery: Reliable Software Releases through   Build, Test, and Deployment Automation by ...
RECOMMENDED READING3. Release It!: Design and Deploy Production-Ready   Software by Michael T. Nygard                     ...
RECOMMENDED READING4. Pragmatic Project Automation: How to Build, Deploy, and   Monitor Java Applications by Mark Clark   ...
USEFUL LINKS   http://martinfowler.com/articles/continuousIntegration.ht    ml - the main article about CI from Martin Fo...
Upcoming SlideShare
Loading in...5
×

03 - Continuous Integration

2,069

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,069
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
102
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • Рад приветствовать вас на очередном тренинге серии, посвященной конфигурационному менеджменту. И мы будем рассматривать Continuous integration.Continuous integration – очень заезженная тема. Об этом говорят все, кому не лень. Практика continuous integration стала практически незаменимой в большинстве проектов и вместе с этим приобрела привкус «попсовости» и обсосанности со всех сторон. Но тем не менее, всё равно встречаются такие люди, которые не знают об этой практике. Дошли слухи о том, что в Днепропетровске НИКТО кроме того, что вообще не использует CI, так еще и не знает о том, что это такое! Если кто-то среди присутствующих есть из Днепропетровска, можете поднять руку и сказать пару слов в свою защиту. Кроме того, что я рассказываю о том же, о чем и практически все остальные пропагандисты (инструменты, workflow), я еще и попробую вдохнуть новую жизнь в понятие непрерывной интеграции показав некоторую доселе невидимую грань. екОсобенностью данного тренинга является то, что я его провожу впервые. Остальные тренинги серии в том или ином виде уже достигали внимания слушателей. Этот же тренинг я подготовил совсем недавно. Так что должен предупредить о том, что я не уверен насчет того, вложимся ли мы в отведенные 1.5 часа времени.
  • У сегодняшнего тренинга две цели.Первая - показать, что современный проект и вправду не может обойтись без практики continuous integration.Вторая – установить взаимосвязь между практикой непрерывной интеграции и соответствующей процессной области CMMI, которая называется Product Integration.
  • Мы рассмотрим следующие вопросы:Что такое CIЗачем это вообще надоБез чего CI невозможенСамый общий workflow – действия, входящие в число стандартных при организации процесса непрерывной интеграции Как CI влияет на весь процесс разработкиИнструменты и их особенностиОписание случаев, когда CI не нужен или неэффективенНовая грань непрерывной интеграции – чего не хватает в функциональности и базовых идеях существующих инструментовСвязь непрерывной интеграции и модели зрелости процессов.
  • Начнем с базовых идей. Опрос на тему использования практики CI
  • Самый первый и самый главный вопрос – что же такое непрерывная интеграция?
  • Есть несколько смежных формулировок что такое непрерывная интеграция. В первой лекции я говорил пару слов об инженерных практиках и о том, что это объединение двух вещей: 1) идей по поводу того, как разрабатывать ПО эффективно, 2) инструментов, реализующих эти идеи. Непрерывная интеграция – это как раз такая инженерная практика. Это также подход, помогающий уменьшить риски при разработке ПО. В списке рекомендованной литературы есть книга o CI, которая так и называется – Improve software quality and reducing risksНепрерывная интеграция – это еще один шаг на пути к автоматизации процессов разработки. Этот шаг следующий после автоматизации сборок.
  • Главным идеологом непрерывной интеграции является Мартин Фаулер. Поэтому на вопрос зачем нам нужна непрерывная интеграция я отвечу его словами:Мартин плавно подводит к ответу, говоря о том, в той ситуации, когда команда интегрирует свою работу часто, причем когда частота эта достигает иногда нескольких интеграций в деньнепрерывная интеграция позволяет избежать интеграционных проблем, что ведет кразработке целостного ПО быстрееКроме того, CI – это одна из практик экстремального программирования, идеологом которого также является Мартин Фаулер. Причем, это единственная практика ХР, которая входит в число практик конфигурационного менеджмента. Так как экстремальное программирование претендует на то, чтобы быть полноценной методологией разработки, факт упоминания CI среди практик указывает на ее важность. Опустив из рассмотрения, риски, качество и прочую невидимую лабудень, которую сложно пощупать, перейдем к тому, что же будет видимым результатом непрерывной интеграции. И таким видимым результатом является постоянное наличие свежих сборок приложения. Без нашего вмешательства.
  • Не всё можно совместить так, чтобы составные части успешно работали вместе. Причем даже если это можно сделать вручную, не всегда процесс интеграции можно автоматизировать. Как мы уже знаем, автоматизация интеграции – это ключ к возможности выполнять интеграцию непрерывно (continuously).
  • нужно выполнить несколько условий для того, чтобы практика непрерывной интеграции успешно и (что немаловажно) полноценно выполнялась, соответствуя изначальной идее и концепции.Исходный код должен храниться в системе контроля версий.Сборки должны быть автоматизированы. Кроме этого, довольно общего условия, я рекомендовал бы использовать специальный тип сборок – интеграционный. К сожалению, я не смог подробно на этом моменте остановиться во время рассказа об автоматизации сборок. Очень часто сборки автоматизируются единственно с целью именно непрерывной интеграции. Но нужно этот тип сборок отдельно выделять и не путать с остальными, ведь не единой непрерывной интеграцией жив разработчик. В идеалетакжедолжноиспользоватьсяюнит-тестирование, непосредственное выполнение которого входит в задачу автоматизации сборок.Совершенно замечательно, если для выполнения интеграции используется отдельная рабочая станция. И, конечно же, нам понадобится инструмент для выполнения непрерывной интеграции. Такой инструмент будет называться сервером непрерывной интеграции. Хотя, нужно заметить, что это не обязательно должна быть отдельная рабочая станция. (Server, serve – обслуживать)
  • Как же работает непрерывная интеграция? Как этот процесс организуется и что сюда входит? Процесс начинается тогда, когда разработчики добавляют изменения в репозиторий исходного кода. Сервер непрерывной интеграции отслеживает то, что произошли изменения в репозитории и автоматически последняя актуальная версия исходного кода попадает в рабочую директорию CI-сервера. Предполагается, что CI-сервер знает, где среди всей кучи исходников искать билд-скрипт. Он находит его и запускает. После выполнения всех действий, входящих в автоматизированную сборку приложение оказывается готовым для использования/тестирования/еще чего-то. (Опрос: для чего готово приложение после выполнения непрерывной интеграции?)
  • Те же яйца – вид сбоку. На первом изображении - репозиторий исходного кода. На втором – файловая система сервера непрерывной интеграции. Это рабочая копия. Исходники обновляются именно здесь. Средибольшогоколичествафайлов находится билд-скрипт. Который используется для запуска сборки и развертывания. Приложение попадает в некоторую директорию на сервере развертывания. Можно запутаться в обилии мест в которых можно найти ресурсы нашего проекта. Но суть в том, что все эти места нужны для разных целей. Вот
  • Нам нужно знать, какие существуют инструменты для организации процесса непрерывной интеграции и какими специфическими особенностями они обладают.
  • Расширенная непрерывная интеграция и управление сборками означают, что инструменты облегчают кроме всего прочего еще и тестирование (для разных платформ), а также развертывание приложения. Тоже на разные платформы. Это то, что касается подходу к управлению жц приложения. Разные инструменты по разному покрывают фазы жц. ОПРОС на тему использования инструментов непрерывной интеграции
  • ANT + CruiseControl = standards de facto
  • NAnt + CruiseControl.NET
  • POM – project object model. Convenient for the new projects. It is a nightmare for legacy code.
  • First 5 – java Insure –c++Ncover - .netXdebug – phpCoverage.py - pythonThere are code coverage tools embedded into the IDE: Netbeans, IntelliJ IDEA, eclipse, VS (CTC++, TestDriven.NET, etc)
  • First 5 – java Insure –c++Ncover - .netXdebug – phpCoverage.py - pythonThere are code coverage tools embedded into the IDE: Netbeans, IntelliJ IDEA, eclipse, VS (CTC++, TestDriven.NET, etc)
  • Other tools:Jdepend, PHP_Depend, PHP-sat, LintPyLintPyCheckerRATS – multilingual
  • CPD is the plugin for PMDCloneAnalyzerCloneDRConQATCPMinerCCFinder
  • More about AgileSCM in the next section (advanced continuous integration)
  • Это были основы. Сейчас я буду углубляться в тонкости всего того, что может быть связано с непрерывной интеграцией.
  • CI establishes some basics of configuration management and development policy. При использовании практики непрерывной интеграции неизбежной будет ее влияние как на весь процесс разработки, так и на отдельные его составляющие. При внешней видимой простоте того, что происходит во время непрерывной интеграции, более пристальное рассмотрение выявляет, что CI достает своими щупальцами достаточно далеко. И возникает множество вопросов, требующих ответа. Так, к примеру, длительное использование практики CI со временем ведет к необходимости возникновения политики коммитов. Когда направления разработки (ветки), подлежащие непрерывной интеграции, должны находиться под присмотром, исключая возможность вносить в репозиторий какие попало изменения.Это также отражается в правиле “don’t break the build” («не поломай сборку», «сборки не ломать!», «недопущение поломок сборок»). На сайте http://www.youbrokethebuild.com/ собраны замечательные плакаты, созданные с целью мотивировать людей избегать поломок сборок. Я не стал вставлять в презентацию пример плаката, так как там изображена бабушка, показывающая неприличный знак. Как можно избежать поломок? Нужно делать локальные сборки и проверять, что всё работает.Принцип внесения в репозиторий изменений каждым разработчиком команды каждый день подразумевает возможность коммуникации – каждый разработчик видит то, что делают другие разработчики. Таким образом легко устраняются интеграционные проблемы и конфликты участков кода. Но нужно упомянуть о том, что в связи с этим принципом может возникнуть ситуация слишком частых сборок приложения. Особенно когда в команде достаточно много разработчиков, и интеграционные сборки выполняются достаточно длительное время. Поэтому еще одним принципом будет слежение за тем, чтобы сборки выполнялись быстро. Причем разные фазы сборок могут занимать разное время. Лучше когда то, что выполняется быстро (к примеру, самые простые тесты) выполняется первым. Таким образом реализуется принцип управления сборками fail the build fast. CI позволяет кроме сборок также автоматизировать и развертыванияНо нужно учитывать, что понятие сборок будет первичным по отношению к понятию развертываний. В любом случае сборки выполняются первыми.Еще один принцип разработки, на который CI влияет напрямую – это непрерывное проектирование (continuous design). Это принцип экстремального программирования, подразумевающий то, что дизайн системы постоянно меняется в связи с постоянным влиянием тех или иных факторов. Причем изменение дизайна системы происходит мелкими шагами. Непрерывная интеграция позволяет отследить влияние нового дизайна системы так же пошагово, постепенно, используя возможности юнит-тестирования. Таким образом удается избежать «большого взрыва» при объемном редизайне системы или ее отдельных модулей.
  • Давайте подробнее рассмотрим правило о «недопущении поломок сборок». Что это правило означает и как можно избежать этих поломок?Исходный код нужно как следует тестировать перед добавлением изменений в репозиторийНужно избегать зависимости от локальных ресурсов, не сохраненных в системе контроля версий или которых попросту нет на интеграционном сервере. Также по возможности нужно избегать хардкода свойств и ссылок на ресурсы. Обязательно пишите тесты для покрытия наиболее часто встречающихся проблем.Убеждайтесь в том, что инспекции выполняются успешно. Это самое печально-смешное – когда сборка ломается из-за того, что мы неправильно отформатировали код. Поломанная сборка означает одну простую вещь – независимо от причины поломки, исходный код, который соответствует ветке, в которой поломка произошла, использовать нельзя (или не рекомендуется) до тех пор, пока причина поломки не будет ликвидирована.Часто следование этому правилу становится, своего рода, одержимостью.
  • Давайте поговорим об этой одержимости и ее причинах.Довольно часто получается так, что невозможно воспроизвести интеграционную проблему без добавления изменений в репозиторий исходного кода. Конечно, нужно по максимуму избегать и предотвращать такие ситуации, когда некоторая проблема воспроизводится при специфических обстоятельствах. Но такие ситуации случаются. К примеру, еслимы разделяем сборки по типам: интеграционные и приватные, в число задач приватных сборок могут не входить некоторые задачи. Такие как, например, выполнение перформанс-тестов, покрытия исходного кода юнит-тестами или генерация документации. Это один пример. Вероятность того, что поломка произойдет во время этих фаз, довольно невысока. Но вот другой пример. В моей практике встречался случай, когда существовал всего один тип сборки – интеграционный. Было практически невозможно или нецелесообразно (долго) выполнять локальные сборки. Кроме того, было невозможно запустить отдельные фазы автоматизированных сборок для того, чтобы проверить, что эти фазы проходят успешно. Это всё результат недостаточно ответственного подхода к организации сборок. Единственный способ, которым можно было наверняка проверить изменения и то, что они собираются – закоммитить их и позволить начаться интеграционной сборке, предварительно внимательно происследовав код на возможные ошибки. Человеческий фактор иногда срабатывал – и сборки ломались. Кроме того, сборки могут ломаться по совершенно непонятным причинам. Предположим мы все таки сделали локальную сборку и она поломалась. Оказывается, что можно потратить человекочасы на поиск ошибок в чужом коде или модуле, так как причиной поломки будут обоюдные изменения в разных модулях. Но если вдруг локальная сборка прошла успешно и вы добавили изменения в репозиторий с последующим выполнением неудачной интеграционной сборки, всё время, пока вы будете корпеть над проблемой, именно вы будете тем человеком, который поломал сборку. Может показаться, что это довольно невероятная ситуация. Но такие проблемы возникают достаточно часто в проектах с недостаточно продуманной архитектурой с недостаточно уделяемым вниманием вопросам конфигурационного менеджмента. Если пытаться избегать подобного рода ситуаций, каждое добавление в репозиторий изменений становится настоящим наваждением и начинает забирать слишком много времени. Очень тонкий политический нюанс. Отношение к правилу о «недопущении поломок сборок» может быть свидетельством того, насколько зрелой является команда и насколько команда осведомлена о тонкостях всех вопросов, связанных с непрерывной интеграцией, управлением сборками итд.Естьстатьясотрудникамайкрософт, жалующегося на то, насколько отстойным является правило о «недопущении поломок сборок», которое превратилось в определенное время в бюрократию.
  • Nightly builds – compromise between team size and project size. NB is not effective if there are too many developersArchitectural issues: AOP, decomposition, modularization, loose coupling, OOD, Large proj to small projs = dependencies management. There should be optimal size of the project in LOCBuild policy established such types of builds as: private, local, integration, release. There is an example of build policy in ‘Build and Deployment management’ training. Билдполиси также подразумевает наличие разных типов веток, которые собираются по разным правилам. Для одних веток используются более строгие вариации правила о «недопущении поломок сборок», а вторых – более демократичные. ОПРОС на тему правила о сломанных билдах
  • Непрерывная интеграция – замечательная практика, решает кучу проблем.Но, тем не менее, есть случаи, когда использование CI оказывается не совсем эффективным. Такими случаями являются:Использование распределенных систем контроля версий. DVCS предполагают, что иногда один из репозиториев выделяется в качестве центрального. Но кроме того, что это происходит не всегда, в центральный изменения могут поступать не так часто (вспомним принцип commit every day).CI часто бывает совсем не нужна для экспериментальной разработки (одно из проявлений экспериментальных разработок – это использование распределенного контроля версий, а мы уже сказали, что для DVCS CI не совсем эффективен)И для маленьких проектов. В этих двух случаях CI требует несопоставимо много накладных расходов на поддержку и организацию.Из тренинга, посвященного управлению сборками и развертываниями вы помните о том, что приложение делится на функциональную часть и часть данных. Для данных используется совершенно другой подход к конфигурационному менеджменту, нежели для функциональной части – используется интеграция баз данных. И совершенно бессмысленным становится использование CI для интеграции баз данных.Для некоторых типов проектов, не связанных с разработкой, CI не нужен.
  • How would we define what branches types are there? How could we distinct dev from releaseif branch types are not clearly defined and there is no visualization of inheritance? By two first symbols. N.x (number dot x) means development streamline.Release streamline has two numbers instead (N.M) of number and ‘x’ symbol. Difference in the “who broke the build” policy. Release – more strict, development – more loose. Pay attention to the integration version number pattern. It consists out of 4 symbols. Second and third symbols denote specific cases of integrationN.x.x.L is so called ‘pilot integration’ . It means that integration happens before any build (PA) performed using development streamline codebase. N.x.K.L is ordinary development integration. K number is being incremented after each development build (PA, A, B).N.M.x.L is so called ‘pre-release integration’. It means that integration happens before any build (PA) performed using release streamline codebase.N.M.K.L is fully functional `release integration’.
  • Most detailed description of ideal continuous integration process. И еще более детальное описание идеальногопроцесса интеграции (к сожалению, без упоминания четырехсоставных номеров версий) будет приложено к материалам тренинга. Не нужно сейчас в это вникать и пытаться рассмотреть детали. Цель этого слайда не в иллюстрации чего-то, а в том, чтобы вас заинтересовать и чтобы вы по окончании тренинга заглянули в материалы, выложенные вместе с видео.
  • Есть много возможностей совершенствовать процесс CI.Несколько интеграционных направлений разработки ( не только транк)Разделение на девелоперское и релизное интеграционные направленияВнедрить использование четырехсоставного номера версии. В CruiseControlуже есть такая возможность. Внедрение надлежащего наследования номеров версийИнтеграция «ручных» сборок и релизов. Под ручными сборками подразумеваются либо те, которые выполняются нажатием кнопки в инструменте непрерывной интеграции или создание тега, наличие которого будет правильно определено сервером непрерывной интеграции. Много всего ещеIt is all was made possible due to the introduction of exhaustive versions numbering approach (AgileSCM).
  • Conclusion before we move to the place of CI in CMMIЕще пару слов перед тем, как мы перейдем к рассмотрению места непрерывной интеграции в CMMI модели. Непрерывная интеграция – это всего лишь очередной инструмент или практика. Проект среднего размера должен обязательно использовать эту практикуТак сложилось, что CI используется преимущественно в agile мире. И разработка подхода к нумерации версийAgile SCM – это результат попытки осмыслить какие номера версий должны носить результаты сборок, выполняющихся сервером непрерывной интеграции. Я этим вопросом однажды заинтересовался и… до сих пор не могу остановиться.
  • Transcript of "03 - Continuous Integration"

    1. 1. CONTINUOUS INTEGRATION
    2. 2. TRAINING GOALS Show that there is no way present-day project could be successful without usage ofcontinuous integration practice Establish connection between CMMI product integration process area and continuous integration practice 2
    3. 3. TRAINING PLAN1. What is continuous integration?2. Why do we need continuous integration?3. Prerequisites for continuous integration process4. General CI workflow5. How does continuous integration affect our development process?6. Tools and their features7. When CI is not effective?8. We have "true CI". What next?9. CI and CMMI product integration process area 3
    4. 4. INTRODUCTION TO CONTINUOUS INTEGRATION4 Basic ideas
    5. 5. WHAT IS CONTINUOUSINTEGRATION? 5
    6. 6. WHAT IS CONTINUOUSINTEGRATION?• Integration is when you make everything work together• Continuous is when you make everything work together very often 6• You would go mad if you had to do it manually• That‟s why it is not about manual actions, it is about automation
    7. 7. WHAT IS CONTINUOUSINTEGRATION? Software engineering practice Another step to the Approach development helping to process reduce risks automation 7
    8. 8. WHY DO WE NEED CONTINUOUSINTEGRATION? Martin Fowler:… team integrate their work frequently,… leading to multiple integrations per day.… this approach leads to significantly reduced integrationproblems and allows a team to develop cohesive software more rapidly. CI is the one of the XP practices Allows to have fresh latest build 8
    9. 9. PREREQUISITES FOR CONTINUOUSINTEGRATIONNot everything you can continuously integrate 9
    10. 10. PREREQUISITES FOR CONTINUOUSINTEGRATION Single source code repo (VCS system) Build CI tool automation Separate Self-testing server app (unit- 10 (usually) tests)
    11. 11. GENERAL CI WORKFLOW BuildCommitting (compilation, unit- latest testing, db changes integration, etc) Update by Application is scheduler (on ready CI server) 11
    12. 12. GENERAL CI WORKFLOW changes detected build & update deploycommit ~ repository deployment server continuous integration server 12
    13. 13. GENERAL CI WORKFLOW Check modification Build application 13
    14. 14. TOOLS14 Instruments for continuous integration and their features
    15. 15. TOOLS CLASSIFICATIONCI toolsBuild management toolsUnit testing toolsInspection tools• Code coverage analysis• Static analysis (syntax check, code dependencies)• Copy/paste detectors 15Documentation generation tools
    16. 16. CI TOOLS  CruiseControl  CruiseControl.NET  CruiseControl.rb  JetBrains TeamCity  Apache Hudson  Apache Continuum  Atlassian Bamboo  FinalBuilder  phpUnderControl 16  XInc
    17. 17. CI TOOLS  CruiseControl  CruiseControl.NET  CruiseControl.rb  JetBrains TeamCity  Apache HudsonMost common, flexible, configurable, easy to  Apache Continuum use, de facto choice for Java projects  Atlassian Bamboo  FinalBuilder  phpUnderControl 17  XInc
    18. 18. CI TOOLS  CruiseControl  CruiseControl.NET  CruiseControl.rb  JetBrains TeamCity  Apache HudsonMost common, flexible, configurable, easy to  Apache Continuum use, de facto choice for .NET projects  Atlassian Bamboo  FinalBuilder  phpUnderControl 18  XInc
    19. 19. CI TOOLS  CruiseControl  CruiseControl.NET  CruiseControl.rb  JetBrains TeamCity  Apache HudsonMost successful adaptation of CI principle for the  Apache Continuum interpreted language (Ruby)  Atlassian Bamboo  FinalBuilder  phpUnderControl 19  XInc
    20. 20. CI TOOLS  CruiseControl  CruiseControl.NET  CruiseControl.rb  JetBrains TeamCity  Apache HudsonOne of the best CI tools:  Apache Continuum• pre-tested commit• build agents  Atlassian Bamboo• multi-platform builds  FinalBuilder• build dependencies  phpUnderControl• comprehensive statistics and reporting 20  XInc
    21. 21. CI TOOLS  CruiseControl  CruiseControl.NET  CruiseControl.rbTagging after successful build, distributed builds  JetBrains TeamCity  Apache Hudson  Apache Continuum  Atlassian Bamboo  FinalBuilder  phpUnderControl 21  XInc
    22. 22. CI TOOLS  CruiseControl  CruiseControl.NET  CruiseControl.rb Distributed builds  JetBrains TeamCity  Apache Hudson  Apache Continuum  Atlassian Bamboo  FinalBuilder  phpUnderControl 22  XInc
    23. 23. CI TOOLS  CruiseControl  CruiseControl.NET  CruiseControl.rbFocused on processJetBrains TeamCity just a feature  of building, CI is  Apache Hudson  Apache Continuum  Atlassian Bamboo  FinalBuilder  phpUnderControl 23  XInc
    24. 24. CI TOOLS  CruiseControl  CruiseControl.NET  CruiseControl.rb CI tools written in PHP for PHP projects  JetBrains TeamCity  Apache Hudson  Apache Continuum  Atlassian Bamboo  FinalBuilder  phpUnderControl 24  XInc
    25. 25. CI TOOLS  CruiseControl  CruiseControl.NET  CruiseControl.rbYet another CI tool written in TeamCity PHP projects  JetBrains PHP for  Apache Hudson  Apache Continuum  Atlassian Bamboo  FinalBuilder  phpUnderControl 25  XInc
    26. 26. CI TOOLS Too many tools All are great All have the same principle But each has specific featuresDiagrams, metrics, reporting Integration with SCM tools Notification Interface, usability Distributed builds Different ALM approaches 26
    27. 27. CI TOOLS. ALM APPROACH Requirements Initiation development & Design management Testing Integration Implementation Maintenance & Deployment Utilization 27 support
    28. 28. CI TOOLS. ALM APPROACH Requirements Initiation development & Design management Basic continuous integration Testing Integration Implementation Maintenance & Deployment Utilization 28 support
    29. 29. CI TOOLS. ALM APPROACH Requirements Initiation development & Design management Basic continuous integration Testing Integration Implementation Extended build management Maintenance & Deployment Utilization 29 support
    30. 30. BUILD TOOLS  Ant  NAnt  MSBuild  Maven  Make  Phing  Rake  … 30
    31. 31. BUILD TOOLS  Ant  NAnt  MSBuild  Maven Most common, flexible, configurable, easy to  Make use, de facto choice for Java projects  Phing  Rake  … 31
    32. 32. BUILD TOOLS  Ant  NAnt  MSBuild  Maven Most common, flexible, configurable, easy to  Make use, de facto choice for .NET projects  Phing  Rake  … 32
    33. 33. BUILD TOOLS  Ant  NAnt  MSBuild  Maven  Makede facto case for Visual Studio and TFS users  Phing  Rake  … 33
    34. 34. BUILD TOOLS  AntBuild management + dependencies management  NAnt for Java projects. Introduced POM concept.  MSBuild  Maven  Make  Phing  Rake  … 34
    35. 35. BUILD TOOLS  Ant Standard de facto for UNIX applications  NAnt  MSBuild  Maven  Make  Phing  Rake  … 35
    36. 36. BUILD TOOLS  AntImplementation of build management tool in PHP  NAnt for PHP projects  MSBuild  Maven  Make  Phing  Rake  … 36
    37. 37. BUILD TOOLS  AntImplementation of build management tool in Ruby  NAnt for Ruby projects  MSBuild  Maven  Make  Phing  Rake  … 37
    38. 38. UNIT TESTING TOOLS  Junit  NUnit  CppUnit  PHPUnit  SimpleTest  JSUnit  J3Unit 38
    39. 39. INSPECTIONS TOOLS.TEST COVERAGE Cobertura Atlassian Clover jTest JCoverage CodeCover EMMA Parasoft Insure++ Ncover Xdebug 39 Coverage.py
    40. 40. INSPECTIONS TOOLS.TEST COVERAGE Cobertura Atlassian Clover jTest JCoverage Java CodeCover EMMA Parasoft Insure++ C++ Ncover C# Xdebug PHP 40 Coverage.py Python
    41. 41. INSPECTIONS TOOLS.STATIC ANALYSIS PMD FindBugs JLint FxCop Checkstyle ReSharper PHP_CodeSniffer Yasca 41 NDepend
    42. 42. INSPECTIONS TOOLS.COPY/PASTE DETECTORSCPD (Copy paste detector)CheckstyleSimianJplagAtomiqClone diggerPBA 42
    43. 43. DOCUMENTATION GENERATIONTOOLS Doxygen JavaDoc NDoc CppDoc phpDocumentor pyDoc RDoc 43
    44. 44. OTHER TOOLS Source code Dead code metrics (loc) detectors Profiling … 44
    45. 45. CI IN EPAM MICROSOFTTECHNOLOGIES DIVISIONProject Project Product Primary CCNET Code Analysis Unit Test Copy & Automat Automate Language tools testing coverage Paste e build deploymen tools detectors delivery tACT-INT C# x - x (Unit) - - - -ACT-LVI C# x x (FxCop, PBA) x - - - -CON-GEN C#, ASP.NET - - - - - - -EPM-UTIL C#, ASP.NET x x (FxCop,PBA) x (NUnit) x (NCover) x (Simian) + +ESS-MSFT - - - - - - -FSTIDX C#, ASP.NET x x (PBA) x - - - -ICPDP C# x - - - - - -LOGIDEX Java, J#, C#, ASP.NET - - - - - - -LSEEC C# x x (FxCop, PBA) x (NUnit) - x (Simian) - +MIS-OPC C# x x x - - - -MIS-SPR C# x x x (Nunit) x - - -MultAPI VBScript - - - - - - -MultCons C# x x (FxCop, PBA) - - x (Simian) - -MultData C#, C++, HTML, VB x - x - - - -MultEDG C++, C# - x (FxCop) x - - x -Mult-IPAS C#, C++ x x (FxCop) - - - - -MultRIN C# - - x - - - xMult-Torn C++ - - x - - - -
    46. 46. CI IN EPAM MICROSOFTTECHNOLOGIES DIVISIONProject Project Product Primary CCNET Code Analysis Unit Test Copy & Automat Automate Language tools testing coverage Paste e build deploymen tools detectors delivery tRTRS-AAAM C# - - - - - - -RTRS-MTST C#, ASP.NET - x (FxCop) - - - - -RTRS-RKSD C# x x - - x (Simian) - -RTRS-RKWM C# - x - - - - -TAK-PBLD C# - x (FxCop) x (Nunit) - - - -TRR-ODC (O2I) C#, ASP.NET x x (FxCop,PBA) x (Nunit) - x (Simian) - -TRR-ODC (SapSn) C# x x (FxCop,PBA) - - x (Simian) - - 46
    47. 47. MOST TYPICAL QUESTIONS All the above-described info sounds cool. I feel that it might be useful in my project. But I am not sure I can find enough resources to start and support this activity. EPM-BET project is started long time ago for this purpose. It provides corresponding resources and support There are too many different tools. They are all different. How could I use them both independently and all at once? I recommend to use AgileSCM approach. It uses 47 unified versions numbering which could be used by any mentioned tool.
    48. 48. ADVANCED CONTINUOUS INTEGRATION48 More complex issues related to the continuous integration
    49. 49. HOW DOES CI AFFECTDEVELOPMENT PROCESS? Commit policy (mainlines are on the watch) Dont break the build rule (make local build) Everyone commits to the mainline everyday Keeping the build fast  Run fast tests first We can automate deployment  Build is primary, deployment is secondary Continuous design 49
    50. 50. “DON’T BREAK THE BUILD”RULE Test code properly before checking in Avoid depending on a local resource that is not under version control or does not exist on the target computer. Write tests to cover common problems Make sure local inspections were run successfully Broken build in most cases means that it is impossible or not recommended to use corresponding codebase until it has been fixed 50
    51. 51. “DON’T BREAK THE BUILD”OBSESSION It is often impossible to reproduce integration problem without checking in. You might spend A LOT of time looking for a failure reason in someone‟s else module During that time you will be the one WHO FAILED THE BUILD If you want to avoid such situations, every checking in becomes a nightmare Attitude to the “don‟t break the build” rule may be a detector of how mature the team is. 51
    52. 52. “DON’T BREAK THE BUILD”OBSESSION. SOLUTION Nightly builds instead of builds „on commit‟ Team needs more strict and less strict variations of the “don‟t break the build” rule during different SDLC phases There are architectural issues to pay attention to Sometimes several small projects should be started instead of one large 52 Build policy is to be developed
    53. 53. WHEN CI IS NOT EFFECTIVE? DVCS Experimental development Small projects Interpreted languages without unit-tests When database is being changed too often Types of projects  Documentation (BA, etc)  DB  Support & maintenance 53
    54. 54. WE HAVE "TRUE CI".WHATS NEXT? Building tags Separate builds having different maturity  levels  Codebase structure filtering  Triggering build only for changes in specified list of folders Integration with issue tracking systems Different approach for different SDLC 54 phases
    55. 55. WE HAVE "TRUE CI". WHAT’S NEXT? 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 56 /1.0.x
    56. 56. WE HAVE "TRUE CI". WHAT’S NEXT? 1.x.x 2.x.x/trunk 1.x.0.0 1.x.0.1 1.x.1.0 1.x.1.1 1.x.2.0 2.x.x.0 2.x.x.1 2.x.x.2 2.x.x.3 2.x.x.4 … 2.x.0.0 2.x.0.1 2.x.1.0 2.x.1.1 integration (dev) 2.x.0 2.x.1 2.x.2 builds CI server 1.x.0 1.x.1 1.x.2 1.x.3 1.x.4 1.x.5 builds 1.x.2.1 … 1.x.3.0 1.x.3.1 1.x.4.0 1.x.4.1 1.x.4.2 1.x.4.3 integration (dev) /1.x.x CI server releases 1.0.0 1.0.1 1.0.2 1.0.3 1.0.4 integration (rel) 1.0.x.0 1.0.0.0 1.0.0.1 1.0.1.0 1.0.1.1 1.0.2.0 1.0.2.1 1.0.3.0 1.0.3.1 57 /1.0.x
    57. 57. WHAT NEXT? VERSIONSNUMBERING PATTERNS N.x.x.L pilot integrationintegration N.x.K.L development integration N.?.?.L N.M.x.L pre-release integration N.M.K.L release integration 2.0.x.0 2.0.x.1 2.0.0 2.x.x.0 2.x.x.1 2.x.x.2 2.x.x.3 2.x.x.4 2.x.0 … … 1.x.1.0 1.x.1.1 1.x.2 1.1.x.0 1.1.0 1.x.2.0 1.x.2.1 1.x.3 1.x.3.0 1.x.3.1 1.x.4 dev rel 58 N.x N.M 1.0.x.0 1.0.0 1.0.0.0 1.0.0.1 1.0.1
    58. 58. 59
    59. 59. CONCLUSION Thereis a lot of possibilities to make your continuous integration better:  Several integration streamlines (not only trunk)  Development and release integration streamlines  Introduce version number consisting of four symbols  Proper version number inheritance  Integration of builds and releases  …
    60. 60. CONCLUSION CI is another SCM tool (practice) Middle size project should definitely have it. It is used mostly in agile world Agile SCM is the result of attempt to understand what version should have artifacts which are being built by CI server
    61. 61. AFTERWORD62
    62. 62. RECOMMENDED READING1. Continuous Integration: Improving Software Quality and Reducing Risk by Paul M. Duvall, Steve Matyas, Andrew Glover 63
    63. 63. RECOMMENDED READING2. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation by By Jez Humble, David Farley 64
    64. 64. RECOMMENDED READING3. Release It!: Design and Deploy Production-Ready Software by Michael T. Nygard 65
    65. 65. RECOMMENDED READING4. Pragmatic Project Automation: How to Build, Deploy, and Monitor Java Applications by Mark Clark 66
    66. 66. USEFUL LINKS http://martinfowler.com/articles/continuousIntegration.ht ml - the main article about CI from Martin Fowler http://www.infoq.com/news/2009/03/Continuous- Deployment - Beyond Continuous Integration: Continuous Deployment http://radar.oreilly.com/2009/03/continuous-deployment- 5-eas.html - Continuous Deployment in 5 easy steps http://www.proudlyserving.com/archives/2007/10/fear_of _a_broke.html - „fear of the broken build‟ effect http://lib.custis.ru/Continuous_Integration - wiki about Continuous Integration in Russian http://habrahabr.ru/blogs/php/91777/ - Providing quality for web applications (rus) http://www.youbrokethebuild.com/ - great posters created with the purpose of motivation people avoid breaking the build 67
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×