Автоматизация для программистов: Антишаблоны постоянной интеграции

Как не стоит поступать, если вы решили внедрить CI

Хотя постоянная интеграция (continuous integration – далее CI) может быть весьма эффективным средством снижения рисков проекта, она требует особого внимания к повседневному процессу создания программного кода. В этой статье из серии "Автоматизация для программистов эксперт по автоматизации и соавтор книги Continuous Integration: Improving Software Quality and Reducing Risk Пол Дювал представляет набор "антишаблонов" CI, и что более важно, покажет, как избежать их.

Пол Дювал, директор по технологиям, Stelligent Incorporated

Пол Дювал (Paul Duvall) – директор по технологиям консалтинговой компании Stelligent Incorporated и идейный лидер, помогающий командам разработчиков оптимизировать гибкую (agile) разработку ПО. Он является соавтором книги Continuous Integration: Improving Software Quality and Reducing Risk (Addison-Wesley Signature Series, 2007). Он также участвовал в написании книг UML 2 Toolkit (Wiley, 2003) и No Fluff Just Stuff Anthology (Pragmatic Programmers, 2007).



23.11.2009

На всем протяжении моей карьеры я замечаю, что больше узнаю, когда открываю для себя то, что не работает в данной ситуации, нежели то, что работает. Например, когда-то я пренебрегал unit-тестированием, так как считал, что затраченные усилия не стоят полученной выгоды. К счастью, я узнал, что проталкивание непроверенного кода в рабочую среду не работает, так что я начал писать unit-тесты.

Похоже, отрасль в целом тоже следует такому стилю обучения. Было придумано даже новое слово для приемов, которые не работают в определенном контексте: антишаблоны. В самом общем смысле антишаблоны – это решения, которые кажутся выгодными, но в конце приводят к противоположному эффекту.

Ложное кажется истинным

К сожалению, я обнаружил, что неопытные команды, пытающиеся внедрить приемы CI, имеют большие шансы столкнуться с рядом антишаблонов, которые определенно могут привести к срыву планов вместо ожидаемых преимуществ. К несчастью, понятие CI часто понимается неверно, и поэтому часто приходится слышать: "CI не работает для больших проектов" или "наш проект настолько уникален, что CI не будет работать" когда на самом деле источник проблемы не CI, а неэффективное приложение, нереалистичность или конкретные подходы, которые привели к крушению ожиданий.

Об этой серии статей

Как разработчики, мы занимаемся автоматизацией процессов для конечных пользователей, но многие из нас игнорируют возможности автоматизировать собственный процесс разработки. Серия статей "Автоматизация для программистов" посвящена исследованию практического использования автоматизации процесса разработки ПО и учит, когда и как успешно применять автоматизацию.

Ради CI я намерен установить рекорд и подробно описать в этой статье целых шесть антишаблонов:

  • Infrequent check-ins (редкая синхронизация кода) - ведет к задержкам в интеграции.
  • Broken builds (поврежденные сборки) - мешают командам переходить к следующим задачам.
  • Minimal feedback (минимальная обратная связь) - мешает действовать.
  • Spam feedback (чрезмерная обратная связь) - заставляет получателей игнорировать сообщения.
  • Slow machine (медленная система) - задерживает получение обратной связи/
  • Bloated build (перегруженная сборка) - снижает скорость получения обратной связи.

Если вы уже давно используете CI, скорее всего вы уже знакомы с последствиями этих антишаблонов. Это нормально, но если они возникают слишком часто, это ограничит многочисленные преимущества. Так что если необходимо ограничить частоту возникновения и последствия этих антишаблонов, вам стоит ознакомиться с этой статьей.


Задержка интеграции из-за редкой синхронизации кода

Название: Infrequent Check-in (редкая синхронизация кода)

Антишаблон: Файлы исходного кода долго остаются без синхронизации (checked out) с репозитарием из-за большого количества изменений, необходимых для решения поставленной задачи.

Решение: Часто синхронизировать небольшие порции кода.

Идея CI состоит в том, что команды могут быстро получать обратную связь о состоянии кода, находящегося в разработке, а такая частая интеграция ПО снижает затраты времени и количество проблем по сравнению с усилиями, необходимыми для более традиционной "поздней" интеграции ПО в стиле "большого взрыва". Эффективная CI, однако, подразумевает, что изменения делаются регулярно, чтобы сборки можно было выполнять часто. Если код длительное время "живет" на системе разработчика, а не в репозитарии, могут возникнуть нежелательные явления, поскольку другие части системы тоже изменяются.

Синхронизация с системой контроля версий хотя бы раз в день избавляет от проблем с интеграцией

Стандартное эмпирическое правило – это загружать код в систему контроля версий по меньшей мере раз в день. Я прибегаю к такому эффективному приему: если я чувствую, что мне нужен перерыв, то сначала я смотрю, нахожусь ли я в точке, где можно запустить локальную сборку, и загружаю свой код в систему контроля версий. А затем уже устраиваю себе перерыв.

На практике, если код редко загружается в систему контроля версий, интеграция откладывается, и чем дольше такая задержка, тем больше усилий потребуется для того, чтобы разобраться с нежелательными последствиями (например, если изменения другого программиста повлияли на ваш код). На проекте, в котором используется CI, я рекомендую разработчикам загружать свой код в систему контроля версий по меньшей мере ежедневно, но считаю, что гораздо лучше синхронизировать код несколько раз в день.

Упростите себе жизнь – используйте небольшие задачи

Я уже представляю гневные отповеди разработчиков, которые неизбежно заявят, что трудно ежедневно синхронизировать код, когда они настолько заняты изменением множества файлов. По сути дела, это заявление доказывает мою точку зрения – чтобы ежедневно загружать изменения в систему контроля версий, необходимо думать в терминах более мелких задач. На самом деле необходимо разбить задачи по написанию кода на небольшие фрагменты работы, чтобы изменения были небольшими.

Вместо того чтобы реализовывать всю функциональность бизнес-объекта за один большой подход, с написанием стандартных методов read(), write(), update() и delete(), можно сначала написать метод read() (и соответствующий тест, разумеется) и затем синхронизировать класс с системой контроля версий, чтобы можно было интегрировать весь код. Затем аналогично реализуется следующий метод, и так пока не будет выполнена вся задача. Так можно максимизировать преимущества CI и гарантировать, что ваш код все время работает с кодом всех остальных участников команды.

Помните, что даже если вы и ваша команда правильно выполняете многие приемы CI, но не загружаете изменения в исходном коде в систему контроля версий по меньшей мере раз в день, ваши преимущества от CI будут минимальными. В большинстве случаев это ведет к ошибочному убеждению, что CI не работает.


Поврежденные сборки замедляют скорость разработки

Название: Broken Build (Поврежденная сборка)

Антишаблон: Сборка остается неработоспособной в течение длительного периода времени, тем самым мешая разработчикам загружать функционирующий код из системы контроля версий.

Решение: Разработчики должны быть немедленно оповещены в случае возникновения сбоя во время сборки проекта, а исправление поврежденной сборки должно стать задачей с максимальным приоритетом.

Неважно, верите вы в это или нет, но исправить сборку проекта становится гораздо сложнее, когда с момента сбоя прошло много времени. Это связано с тем, что появляются файлы, дополнительные изменения и зависимости, которые затрудняют изоляцию дефекта, приведшего к сбою. Следовательно, когда кто-то получает извещение, что процесс сборки проекта был нарушен (через e-mail, RSS или другие механизмы), исправление аспекта, нарушающего нормальную работу, должно стать задачей наивысшего приоритета, в противном случае, чем дольше сборка остается поврежденной (особенно если команда практикует частые изменения), тем сложнее будет исправить ситуацию, когда кто-нибудь возьмется за эту работу.

Сбои в процессе сборки ПО – это не всегда плохо. На самом деле поврежденная сборка позволяет быстро узнать о наличии проблем в продукте. Поврежденные сборки становятся проблемой, если сбои в ходе сборки возникают часто или остаются в сборке надолго. Вряд ли вам захочется покинуть офис на целый день, если процесс сборки ПО был нарушен ошибкой.

Сборки, которые никогда не ломаются

Не будем торопиться. Часть приходиться слышать от разработчиков заявления типа "ваш процесс сборки ПО никогда не должен ломаться!". Это плохой совет. Большинство стандартных ошибок, возникающих в ходе сборки проекта, например, отсутствующие файлы или "сломанные" тесты, можно предотвратить, однако сборки, которые не ломаются, могут говорить еще и о другом. В ходе сборки проекта может не делаться ничего серьезного, возможно только компиляция и несколько unit-тестов. Я называют подобное состояние Continuous Ignorance (постоянное неведение) и, возможно, это даже хуже, чем часто получать ошибки в ходе сборки проекта.

Внутренние сборки снижают количество дефектов

Один из наиболее полезных приемов, который снижает вероятность сбоя в процессе сборки проекта, - это выполнение внутренней (собственной) сборки до загрузки кода в репозитарий системы контроля версий. Ниже в общем виде описаны действия для выполнения внутренней сборки:

  1. Загрузить исходный код из репозитария.
  2. Внести в код локальные изменения.
  3. Выполнить обновление из репозитария для интеграции с изменениями, внесенными другими разработчиками.
  4. Запустить локальный процесс сборки.
  5. Если сборка проекта прошла успешно, то загрузить изменения в репозитарий.

На рисунке 1 показано практическое применение этого приема. Обратите внимание, что рабочий процесс предусматривает частую синхронизацию с репозитарием, обеспечивая периодическую загрузку кода в систему и ограничивая количество сбоев при сборке проекта, – то есть решая две задачи одновременно!

Рисунок 1. Запуск внутренней сборки для снижения количества сбоев интеграционных сборок проекта
Рисунок 1. Запуск внутренней сборки для снижения количества сбоев интеграционных сборок проекта

Выполняя внутренние сборки перед загрузкой исходного кода в систему контроля версий (которые мы, конечно, делаем часто), можно предотвратить много типичных ошибок, приводящих к повреждению сборки, и тем самым сэкономить время и нервы.


Помехи в работе из-за минимальной обратной связи

Название: Minimal Feedback (минимальная обратная связь)

Антишаблон: Команда решает не рассылать извещения о статусе процесса сборки проекта, поэтому участники не узнают, что в ходе сборки проекта возникла ошибка.

Решение: Использовать различные механизмы обратной связи для информирования о статусе сборки проекта.

Часто при настройке CI-системы команда решает, что получать электронная почта – это спам, поэтому принимается решение, что "пока" никаких извещений рассылаться не будет. Однако нельзя предпринять действия, если нет никакой обратной связи от процесса сборки. На самом деле обратная связь – это один из важнейших аспектов CI; сказав это, важно не забывать, что также важно, чтобы обратная связь была эффективной.

Часто при настройке CI-системы команда решает, что получать электронная почта – это спам, поэтому принимается решение, что "пока" никаких извещений рассылаться не будет. Однако нельзя предпринять действия, если нет никакой обратной связи от процесса сборки. На самом деле обратная связь – это один из важнейших аспектов CI; сказав это, важно не забывать, что также важно, чтобы обратная связь была эффективной.

Раскройте свои творческие способности

Настроить Ambient Orb очень просто. В листинге 1 показано, как настроить Ambient Orb в сценарии Ant с помощью open source-задачи OrbTask от Quality Lab:

Листинг 1. Использование задачи Ant для работы с Ambient Orb
<target name="notifyOrb" >
  <taskdef classname="org.qualitylabs.ambientorb.ant.OrbTask"
    name="orb" classpathref="orb.class.path"/>
	<orb query="http://myambient.com:8080/java/my_devices/submitdata.jsp"
	  deviceId="AAA-9A9-AA9"
	  colorPass="green"
	  colorFail="red"
	  commentFail="Code+Duplication+Threshold+Exceeded" />    
  </target>

В листинге 1 задача настроена так, чтобы менять цвет шара на зеленый в случае успешной сборки и на красный в случае сбоя. На рисунке 2 изображен зеленый шар, вероятно, говорящий о том, что последняя сборка проекта прошла успешно:

Рисунок 2. Проект успешно собран!
Рисунок 2. Проект успешно собран!

Применение творческих подходов позволяет команде может использовать различные механизмы обратной связи, позволяющие довести до участников информацию о статусе процесса сборки. Более того, эти подходы облегчают само вхождение в стиль CI; также они позволяют при необходимости легко заметить, что возникла проблема, требующая действия.

Другие возможные механизмы оповещения:

  • RSS-потоки
  • Мониторы на панели задач, например, CCTray для CruiseControl
  • Устройства с интерфейсом X10 (например, лава-лампы)
  • Обмен сообщениями через Jabber и т.д.
  • SMS (текстовые сообщения) для тех, кто мало получает их от своих друзей и родственников

Одно замечание: Необходимо удерживать баланс между слишком большим и слишком малым объемом информации. Механизмы для предоставления обратной связи должны меняться и периодически настраиваться в зависимости от рабочей среды. Например, для команд, расположенных в одном месте, может быть эффективным использование звукового сигнала (например, пожарная сирена при возникновении сбоя в ходе сборки проекта); однако другие команды могут предпочесть Ambient Orb (который не напугает вас резким звуком, если вы в этот момент размышляете).


Холодная рука спамера

Название: Spam Feedback (чрезмерная обратная связь)

Антишаблон: Участники команды быстро оказываются заваленными e-mail сообщениями о статусе процесса сборки (удачном, неудачном и всех возможных промежуточных состояниях) до такой степени, что начинают игнорировать сообщения.

Решение: Обратная связь сводится к сжатому объему важнейшей информации, чтобы люди не получали лишней информации.

Аналогично антишаблону с нехваткой обратной связи часто находятся команды, которые наивно решают, что все и всегда должны получать обратную связь (например, электронную почту) каждый раз, когда CI-сервер выполняет какое-то действие. Такой избыток информации буквально вопиет: "игнорируйте меня!"; обратной связи слишком много, и команда быстро начинает рассматривать обратную связь от системы CI как спам. Зато когда происходит что-то действительно серьезное (например, действительно возникает сбой в ходе сборки), это может пройти незамеченным.

Точное определение целевой аудитории защищает от спама

В листинге 2 приведен конфигурационный файл CruiseControl, показывающий пример эффективного использования рассылки e-mail сообщений. В этом случае технический руководитель всегда получает e-mail сообщения, вне зависимости от того, успешна была сборка проекта или нет, менеджер проекта получает e-mail только в случае сбоя в ходе сборки проекта, также оповещаются разработчики, которые недавно загружали изменения в репозитарий системы контроля версий.

Листинг 2. Отправка e-mail извещений с помощью CruiseControl
<project name="brewery">
...
<publishers>
  <htmlemail 
    css="./webapps/cruisecontrol/css/cruisecontrol.css"
    mailhost="localhost"
    xsldir="./webapps/cruisecontrol/xsl"
    returnaddress="cruisecontrol@localhost"
    buildresultsurl="http://localhost:8080"
    mailport="25"
    defaultsuffix="@localhost" spamwhilebroken="false"> 
    <always address="techlead@localhost"/>
    <failure address="pm@localhost" reportWhenFixed="true"/>
  </htmlemail>
</publishers>	
...

Учитывая, что обратная связь – один из самых важных аспектов системы CI, она заслуживает отдельного обсуждения. Хотя минимальная обратная связь и спамерская обратная связь – это две противоположности, . Когда происходит сбой в ходе сборки проекта, необходимо быстро отправить обратную связь соответствующим людям и предоставить им информацию, необходимую для действий. Если же сборка проекта была успешной, то сообщения следует посылать только некоторым сотрудникам, например, тем, кто вносил последние изменения или занимает руководящие позиции и интересуется такой информацией. Постоянное заваливание всех сообщениями с информацией о статусе проекта – это верный способ быстро снизить преимущества CI-процесса.


Не откладывайте обратную связь из-за медленной системы

Название: Slow Machine (медленная система)

Антишаблон: Если в качестве системы для сборки использовать компьютер с ограниченными ресурсами, это может привести к длительному времени сборки.

Решение: Система для сборки должна иметь диск с оптимальной скоростью, процессор и ресурсы памяти для быстрого проведения сборок проекта.

Много лет назад я участвовал в относительно большом проекте, в котором было более миллиона строк кода, для компиляции которых требовалось более двух часов. Так как мы пытались интегрироваться часто, ожидание, пока команда по управлению конфигурацией пройдет через этот процесс, становилось все более и более болезненным. Конечно, два часа были идеальным вариантом развития событий, так как в процессе сборки часто возникали сбои, и для завершения процесса обычно требовалось несколько дней (вот это было болезненно!). После нескольких недель этого ужасно медленного процесса стало ясно, что правильное решение – это купить систему с достаточным дисковым пространством для всех файлов, выгружаемых из системы контроля версий и создаваемых в результате сборки, быстрым процессором для обработки множества инструкций и достаточным количеством оперативной памяти для запуска тестов и других требовательных к памяти процессов.

Хочется скорости?

С новой системой удалось сократить время этой мегасборки с двух часов до 30 минут; таким образом, выгода от вложения некоторой суммы в современную систему привела к значительной экономии времени команды и денег, а также к более быстрой интеграции ПО (что означало, что мы смогли быстрее обнаруживать проблемы).

Вполне можно начать с использования для проведения интеграционных сборок просто дополнительной рабочей станции, однако мораль этой истории в том, что стоит серьезно задуматься об обновлении компьютера, выполняющего сборку проекта, если становится заметно, что ему не хватает скорости, памяти или дискового пространства; время, сэкономленное за счет ускорения процесса сборки, позволит более быстро получать обратную связь, быстрее исправлять проблемы и переходить к следующей задаче по разработке.


Перегрузка процесса сборки затрудняет быстрое получение обратной связи

Название: Bloated Build (перегруженная сборка)

Антишаблон: Добавление всего подряд в процесс сборки, запускаемый после загрузки изменений в систему контроля версий, например, запуск всех типов автоматизированных инструментов для проверки кода или тестов для оценки нагрузки, приводит к тому, что обратная связь задерживается.

Решение:Канал для процесса сборки позволяет запускать различные типы процессов сборки.

Некоторые команды разработчиков оказываются настолько потрясены всеми процессами, которыми можно добавить в автоматизированный процесс сборки, что забывают, что на выполнение этих действий требуется время. В данном случае напомню о проекте, на компиляцию которого требовалось два часа. Предположим, что выполнение тестов было бы добавлено как часть процесса сборки. При более чем миллионе строк кода сколько времени потребовалось бы для запуска инструмента для анализа статистики для этого кода? Если вам кажется, что восьмичасовой процесс сборки невозможен, то вы заблуждаетесь, так как мне несколько раз встречались подобные ситуации.

Многие склонны все больше перегружать процесс сборки, чтобы .предоставить все больше и больше информации участникам команды. Это нарушает баланс между обеспечением быстрой обратной связи для команды разработчиков и предоставлением другой полезной информации в ходе CI-процесса сборки проекта.

Каналы для эффективных процессов сборки

Если обнаруживается, что процесс сборки занимает слишком много времени, и если уже были внедрены другие приемы для сокращения продолжительности сборки (например, покупка более быстрой системы) и время выполнения тестов было оптимизировано, возможно, необходимо создать решение, известное как build pipeline (канал для процесса сборки). Задача канала для процесса сборки - выполнять длительные процессы в основном асинхронно, чтобы когда кто-нибудь загружает код в систему контроля версий, это не откладывало получение обратной связи.

Например, если сборка проекта занимает более 10 минут, можно подготовить канал сборки, чтобы после того, как кто-нибудь загрузит изменения в репозитарий системы контроля версий, выполнялся исходный нересурсоемкий процесс сборки. Этот "синхронизирующий" процесс сборки может состоять из предположительно простых процессов, типа компиляции и запуска быстрых unit-тестов. В зависимости от успеха исходного процесса сборки может быть запущен второй процесс сборки для выполнения более длительных тестов, инспекции кода и даже, возможно, развертывания на сервер приложений.

Например, в листинге 3 CruiseControl настроен проверять изменения в репозитарии системы контроля версий. Когда он обнаруживает изменения, он запускает делегирующий (delegating) процесс сборки, который вызывает главный сценарий сборки проекта (например, файл build.xml, если используется Ant). В данном случае важно, что CruiseControl выполняет другую задачу из сценария сборки, которая, в свою очередь, запускает облегченный процесс, например, компиляцию и высокоуровневые unit-тесты.

Листинг 3. Конфигурация CruiseControl, проверяющая изменения в коде
<project name="brewery-commit">
...
  <modificationset quietperiod="120">
    <svn RepositoryLocation="http://brewery-ci.googlecode.com/svn/trunk"/>
  </modificationset
...

В листинге 4 CruiseControl настроен проверять наличие изменений через проект brewery-commit (хотя на самом деле он находится не в репозитарии, а в журнальном файле). Когда обнаруживается изменение, CruiseControl запускает другой делегирующий процесс сборки. Этот процесс сборки вызывает тот же самый сценарий сборки, но с указанием другой цели, которая может запустить более длительные процессы, например, функциональные тесты, инспекцию кода и т.д

Листинг 4. Конфигурация CruiseControl для запуска продолжительного процесса сборки
<project name="brewery-secondary">
...
  <modificationset quietperiod="120">
    <buildstatus logdir="logs/brewery-commit" />
  </modificationset>
...

Антишаблон Bloated Build чаще всего упоминается как аргумент в пользу того, почему процесс CI не работает. Но, как можно увидеть, этого не происходит, если воспользоваться каналами для процессов сборки. Эффективный канал для процесса сборки максимально использует правило "80/20": проводит 20% времени сборки в областях, которые приводят к 80% ошибок, возникающих в ходе процесса сборки, таких как отсутствующие файлы, проблемы с компиляцией и отказы тестов. После того как этот процесс завершится и разработчики получат обратную связь, запускается второй процесс сборки, который требует для выполнения больше времени, но может обнаружить 20% других ошибок процесса сборки с таким же приоритетом.


Антишаблоны можно исправить

Антишаблоны CI могут стать препятствием для реализации преимуществ постоянной интеграции, однако подходы, описанные в этой статье, помогают снизить частоту возникновения этих антишаблонов. Мы показали, что:

  • Частая загрузка изменений в систему контроля версий может предотвратить сложные интеграции в будущем.
  • Можно легко предотвратить большинство сбоев в ходе сборки проекта, если запускать собственный процесс сборки перед загрузкой измененного исходного кода в систему контроля версий.
  • Использование различных механизмов обратной связи может предотвратить устаревание информации о статусе процесса сборки, которая в противном случае игнорируется.
  • Точная адресация обратной связи людям, которые могут предпринимать действия, - один из лучших способов информировать участников команды о проблемах в процессе сборки.
  • Покупка системы для выполнения процесса сборки – это ценная инвестиция в ускорение обратной связи для членов команды.
  • Создание каналов для процессов сборки – один из приемов, снижающих перегруженность процесса сборки.

Антишаблоны, описанные в этой статье, встречались мне наиболее часто, но существуют и другие антишаблоны, включая:

  • Continuous Ignorance (постоянное неведение), когда сборка состоит из минималистичных процессов, что приводит к всегда успешному завершению сборки проекта.
  • Процесс сборки работает только на вашей системе, что может увеличить время между тем, когда дефект вносится в проект и когда он исправляется.
  • Bottleneck Commits (узкие места при синхронизации изменений с системой контроля версий), которые имеют тенденцию вызывать сбои в процессе сборки и мешать разработчикам вовремя уходить домой с работы.
  • Intermittent builds (промежуточные сборки), которые откладывают быстрое получение обратной связи.

В следующем году мы разберем другие антишаблоны CI, которые могут помешать получить максимальную отдачу от процесса постоянной интеграции.

Ресурсы

Научиться

  • Automation for the people: Continuous Integration anti-patterns: оригинал статьи (EN).
  • Spot defects early with Continuous Integration (EN) (Andrew Glover, developerWorks, 2007): статья Эндрю Гловера с обзором фундаментальных аспектов постоянной интеграции, которая поэтапно иллюстрирует настройку CI-процесса с использованием лучших технологий с открытым исходным кодом.
  • Continuous Integration (EN) (Martin Fowler, martinfowler.com): статья Мартина Фаулера о постоянной интеграции (Continuous Integration).
  • Continuous feedback (EN) (Paul Duvall, developerWorks, ноябрь 2006 г.): статья о том, как немедленно получать обратную связь при каждом изменении исходного кода.
  • Is Pipelined Continuous Integration a Good Idea?(EN) (infoq.com, сентябрь 2007 г.): ведущие сторонники CI взвешивают аспекты применения каналов для процесса сборки.
  • Safari bookstore: сайт магазина книг по ИТ.
  • Раздел Технология Java сайта developerWorks: сотни статей обо всех аспектах Java-программирования.

Получить продукты и технологии

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Технология Java
ArticleID=449174
ArticleTitle=Автоматизация для программистов: Антишаблоны постоянной интеграции
publish-date=11232009