воскресенье, 21 октября 2012 г.

Run Powershell deploy scripts in parallel

Я являюсь большим поклонником Continues Integration и считаю, что каждый современный разработчик должен иметь возможность в один клик (или автоматически) собрать свой продукт, поставить его на тестовые машины и прогнать по всему этому все имеющиеся тесты. Причем чем быстрее этот процесс проходит и чем надежнее, тем лучше.
Так получается, что части моего продукта ставятся в процессе билда уже на 5 виртуальных машин (а один из прошлых проектов делал тоже самое почти на 40 виртуалок). Сам процесс состоит из отправки HyperV команды на откат машины в snapshot, запуска ее, ожидания загрузки и инсталляции продукта.

В большинстве случаев, с которыми я сталкивался, инсталляция продукта на одну машину совершенно независима от инсталляции на другие. Почему бы это не делать параллельно? Мне замена последовательной установки на параллельную позволила сократить фазу отката с 24 минут до 8 минут.

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

$ps = "powershell.exe" 
$paramstr = "lab1;lab2;lab3;lab4;lab5;lab6;lab7;lab8;lab9;lab0" 
$psparam = "-File .\build\InstallToOneLab.ps1 " 
[System.Diagnostics.Process[]] $procs = $() 
foreach ($labname  in $paramstr.split(";")) 
{ 
    $currentpath = (gl).Path
    $args = $($psparam, $labname, $currentpath)     
    Write-Host "Install new to lab='$labname' with params '$args'" 
    $p = Start-Process $ps -ArgumentList $args  -PassThru -NoNewWindow -RedirectStandardOutput ".\$labname.out" 
    $procs += $p 
} 
$procs | Wait-Process 
Write-Host "Finished all"

Я пытался реализовывать этот скрипт через script-блоки и Job'ы, но увы эти механизмы в моей среде отказывались работать.

суббота, 17 марта 2012 г.

Мотивация писать тесты


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

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

Получается, что перед тем, как начинать говорить о том, как мотивировать разработчиков писать тесты, стоит убедить программистов относится к результатам своей работы более внимательно. Тесты станут уже следствием осознания своей ответственности за результат.

Многие руководители не понимают, зачем им что-то менять, если система и так работает. Для компании Agile методики несут в перспективе прежде всего сокращение затрат на разработку за счет сокращения части подразделений QA, занимающихся неблагодарным трудом ручного тестирования. Сейчас стоимость квалифицированного тестера на рынке не многим ниже стоимости разработчика. Даже если скорость разработчиков и упадет в полтора раза, затраты все равно сократятся. В реальных условиях средняя скорость, скорее всего, вырастет за счет исключения длительного периода ручного регрессионного тестирования в конце каждой итерации.
Также за счет укорачивания фазы QA и уменьшения времени на стабилизацию продукта удастся уменьшить длинну итерации, что позволит бизнесу быть более гибким, легче реагировать на изменения и планировать релизы. Совершенствуя эту модель, можно будет достичь нирваны в виде непрерывной поставки (Continuous Delivery).

Чтобы там не говорили, но умение писать легко тестируемый код, и умение создавать эти самые тесты не берется из воздуха, а ему придется учиться.  А следовательно, как минимум по-началу разработчикам придется выйти из своей зоны комфорта и поучиться чему-то новому. Увы, тяга к познанию и обучению зачастую падает с возрастом. К тому же, если у человека 10-летний опыт работы "по старинке", ему очень не просто объяснить, зачем ему все это надо.  Часто это становится причиной некого противостояния в коллективе: на одной стороне которого оказываются матерые разработчики и тестеры, а на другой те, кто пытается что-то изменить. Хуже когда в этом противостоянии на стороне "ретроградов" находится и начальство. Я самолично общался с директором одной аутсорсинговой компании, который придерживался мнения, что все эти новомодные штуки явление проходящее. 

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

Внедрять автоматизацию тестирования лучше начинать с небольших новых проектов, которые ведут маленькие молодые команды. Это уменьшит потенциальные риски, и поможет легче оценить результат. Для начала внедрения автоматизации лучше те проекты, что имеют веб-интерфеис, и используют среды, для которых уже существует большое количество библиотек и средств для тестирования (например, .NET, Java, Python). Писать тесты для приложении на С\C++ может оказаться не самой легкой, хотя и решаемой задачей.

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

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

Порой многие считают, что их приложение самое критичное в мире. Возможно, есть и такие. Например, если вы пишите (или лучше сказать писали) софт для небезызвестного спутника "Фобос Грунт", для робота-хирурга или марсохода. Но большинство компании, на мой взгляд, несколько пероценивают критичность своих продуктов. Например, софт, работающий на вебе, очень толерантен к ошибкам. Гиганты веб-индустрии работают практически без тестеров, проверяя продукты на небольшом проценте пользователей и имея возможность легко откатить изменения. Многие продукты имеют встроенные средства обновления, которые тоже снижают критичность ошибок, т.к. обновление может быть доставлено пользователям даже без их ведома. В то же время пользователи вполне готовы тестировать софт на себе, часть из них даже очень радуется, если удалось найти ошибку.

Поэтому не стоит бояться трудностей, а стоит попробовать начать их решать. 

четверг, 1 марта 2012 г.

Корпоративные стартапы

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


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


Ответ весьма прост. Забудьте, что вы работает в большой компании, если у вас есть свой проект и команда, вам стоит минимизировать зависимости. В идеале, если вы создаете коробочный продукт, внешние зависимости могут быть сведены только к общению с вашим Product Manager'ом.



  • Вы используете монстро-образную систему контроля версии типа TFS, и вам нужно ждать месяц, чтобы маховик корпоративной системы провернулся, и вам создали репозитории? Не пользуйтесь! Возьмите Git, создание репозитория в нем занимает 1 секунду. А если ваша компания мало мальски разумна, то можно будет достать платный аккаунт на GitHub.
  • Вы завязаны на выделенную команду, которая создает setup'ы для всех продуктов вашей компании? Откажитесь! Пользуйтесь WIX, он прост и бесплатен.
  • У вас есть выделенная команда тестеров, которые требуют, чтобы никто ничего никому не отдавал, пока они не посмотрят это в течении месяца? Пошлите их к черту! Тестер - всего лишь роль. Пусть девелоперы отвечают за продукт, пишут автоматические тесты.
  • Целый отдел аналитиков,  архитекторов и продукт менеджеров пол года рисует UML и пишет бесконечные MRD? Да ваш продукт уже не нужен будет когда они закончат! Делайте короткие итерации, показывайте продукт всем. Максимум, что вам придется, так это немножко изменить сделанное. Уверяю, это будет быстрее, чем ждать идеальные документы. Все равно их поменяют уже после начала работы.
  • От вас требуют бесконечной проектной документации с разбивкой по человеко-минутам? Спасите деревья! Нарисуйте backlog на доске с вашим планом на текущую итерацию или используйте online планировщик типа PivotalTracker
  • Вы зависите от корпортивного багтрекера, который, мягко говоря, даже в момент своего выхода был страшен, а это было 10 лет назад и работе с ним нужно специально учится? Отправьте его на пенсию! Возьмите тот же Youtrack ,он бесплатен для 10 человек, вам хватит. 



Если вы это проделали, то вы уже практически стартап, и ваша эффективность возросла в несколько раз.