Интересна книга: Continuous Delivery

[Hristo Deshev]

Днес я мярнах в блога на Мартин Фаулър: http://martinfowler.com/snips/201007301801.html

Книгата определено изглежда интересна, но не мога да намеря никъде съдържание. Чудя се доколко се концентрира на принципите на постоянния деплоймънт и доколко съдържа конкретни съвети за определени платформи. Последното е адски трудно и определено има нужда от серия рецепти, които са безобразно различни както в направление операционни системи (Windows vs UNIX) така и в направление езици и библиотеки(.NET vs. Java vs. Ruby vs. PHP...). Примерно още отсега мога да ви кажа, че рецепти за Windows и .NET направо няма описани никъде.

Поздрави,

Христо

[Stefan Kanev]

Имаше един уебинар на скоро, в който Кент Бек участваше заедно с двама други. Един от тия другите е автора на тая книга и им звучеше бая отракан, демек очаквам да е добра. Не знаех, че е излязла, но мерси, че каза.

2010/7/31 Hristo Deshev <hri...@deshev.com>

[Liubomir Petrov]

Аз повечeto рецепти дет съм виждал, са взе конзолно базирани (и включват тонове тествания на софтуера, освен от гледна точка на Unit Tests ами + UI Test-ове, пр Selenium).
Ако има инструмент, като Selenium, но за WinForms, то не виждам защо да не можеш набързо да си нацъкаш поредица от стъпки (command line, един вид), според чиито exit codes да ръководят процеса по деплоймент/rollback :)

2010/7/31 Stefan Kanev <stefan...@gmail.com>

[Hristo Deshev]

2010/7/31 Liubomir Petrov <liubomi...@gmail.com>

Аз повечeto рецепти дет съм виждал, са взе конзолно базирани (и включват тонове тествания на софтуера, освен от гледна точка на Unit Tests ами + UI Test-ове, пр Selenium).

И аз конзолни искам. Последното нещо, което ми трябва в билд система са разни гуита.

 

Ако има инструмент, като Selenium, но за WinForms, то не виждам защо да не можеш набързо да си нацъкаш поредица от стъпки (command line, един вид), според чиито exit codes да ръководят процеса по деплоймент/rollback :)

Ако говориш за тестване, да. Не виждам проблем. Аз си мисля за деплоймънт стъпки и ноу хау от типа на правене на инсталатор или конфигуриране на виртуална директория в IIS. Там вече нищо не става набързо. Блъскаш се и откриваш топлата вода за абсолютно всичко. И ако няма някой да те светне да ползваш PowerShell или Ruby (с Rake) като нищо ще скочиш на глупости като msbuild или NAnt и работата отива на кино (been there, done that).

Христо

[Liubomir Petrov]

Май ти сам си реши проблема :)
Само да отбележа, че мислих, че те притесняват GUI проекти, а не Уеб (спомена IIS).
Лично аз ползвам python (fabric) и имам една много проста деплой команда, която ако се преправи може и при теб да тръгне:
 - connect via ssh @ stagging
 - hg tag --local "predeploy-$release_name"
 - hg pull/up
 - sync db (from live)
 - hg tag "testing-$release_name"
 try:

 - run django unit tests
 - restart python/wsgi services (или там каквото се ползва..че те са доста приложения, в твоя случай май ще е нещо общо с IIS)
 - run selenium tests (на локалната машина, но отваря stagging URL-та)

except:

 - hg - remove tag and add new tag as failed-$release_name
 - email notification + console notification (включва и кой е виновен за така стеклата се ситуация..да му се накарам набързо :))
 - revert() (hg update -C predeploy-$release_name and remove tag "predeploy-$release_name")

# ако се сетигне до тук, значи всичко е ок
- hg remove temp tags and add new tag as - deploy-$release_name
- console notification + email notification

Горе долу това е... в твоя случай, може да се пригоди на ruby/git/c#/powershell или там каквото ползваш, просто процедурата ми се струва повече app oriented, защото е много важна частта с тестовете. Ако нещо не работи, трябва да rollback-неш някак (в моя случай, правя заигравка с hg tag-овете...).
Допълнително правя и тагове за успешни деплойменти. Ако случайно, нещо го няма в тестовете и клиентите им крашне лейтър, с 1 ред мога да върна на предишната работеща версия :)

Само да отбележа, че този вариант, които ползвам при тестовете ми работи много добре, но още не е пуснат в "production режим" (напълно). Остана ми да измисля, как да update-вам и rollback-вам базата данни.... биг шит и още не съм го измислил казано честно. Даже, ако някой има някаква рецепта за това ще се радвам да сподели :)

ПС: Зависи от процеса/екипа и доста неща, може да прегледаш и Hudson. Аз си го инсталирах и подготвих да прекарвам през него тестове, но .. нещо при така стеклите се обстоятелства, текущия ми вариант ми допада повече - всичко става от конзолата. Кофтито е, че история на success/failed build-ове (в моя случай, deploys) я има само в пощенската ми кутия, но и това може да оправя някой ден или просто да прекарам Hudson-а да пуска deploy командата на фабрик :)

Любо

2010/7/31 Hristo Deshev <hri...@deshev.com>

[Hristo Deshev]

Добре си го описал и така като гледам и аз правя подобни неща в .NET. Мисълта ми е, че всеки се блъска самичък и ги открива тези работи по трудния начин. Сега например се уча на Scala и ми е много интересно как се деплойва едно Lift приложение (всъщност каквото и да е Java уеб приложение, което можеш да компилираш до war файл) без да рестартираш сървлет контейнера и да имаш даунтайм. Но това е само пример. Много бих се израдвал на книги, които те разхождат през деплоймънта на типично приложение за платформата Х.

2010/7/31 Liubomir Petrov <liubomi...@gmail.com>

...

 

Само да отбележа, че този вариант, които ползвам при тестовете ми работи много добре, но още не е пуснат в "production режим" (напълно). Остана ми да измисля, как да update-вам и rollback-вам базата данни.... биг шит и още не съм го измислил казано честно. Даже, ако някой има някаква рецепта за това ще се радвам да сподели :)

Не може да няма за питоня библиотека за DB миграции вдъхновена от тези в Rails (почти 100% сигурен съм, че в Джанго има такава).

 

ПС: Зависи от процеса/екипа и доста неща, може да прегледаш и Hudson.

Тестовете и демона за постоянно билдване обикновено са ясни. В момента ползвам CruiseControl.NET, който е голямо дърво, но поне работи. Петьо ми рекламира Hudson по скайпа вече, но ще ми трябва истинска причина да седна и да мигрирам към него ей така. :-)

Христо

[Liubomir Petrov]

Ако правилно те разбирам, теб повече те интересува как се деплойват нещата на различни платформи, а не чак толкова CI частта ? :)

Относно джанго и db migration-a, има няколко... но е голямо мазало и или ще счупят някое друго приложение или няма да работят както трябват (постоянно ще реват за confirmation от конзолата, което не е решение при начина ми на деплой :/

Относно Hudson, може и аз да ти го рекламирам по стандартния начин - има плугини за всичко (от git, svn, hg, cvs и т.н. до xunit и т.н.), но лично това дет най-много ме впечатли е страшната физиономия на Чък норис, която мога да си инсталирам само с 1 клик.. :D
Иначе, в моя случай не видях смисъл за Hudson, точно защото нямам какво да билдвам (compilation process), ами само деплойвам .py нещата и съм реди :)

2010/7/31 Hristo Deshev <hri...@deshev.com>

[Miroslav Genov]

Преди малко попаднах на следния пост: http://agiletesting.blogspot.com/2010/08/what-automated-deploymentconfig-mgmt.html. Предполагам, че ще ви бъде интересен. 

Относно deployment'a на java war файлове, ми се струва че един от възможните вариант е с custom proxy server, който може да се управлява. Идеята ми дойде от app-engine deployment'a на google. Там нещата са следните, всяко приложение се качва на техен сървър по http. Deployer'a, който се ползва търси промени във версията и се пращат само промените файлове за да се пести трафик. Предполагам при локален deployment, нещата биха били доста по упростени без да се налага подобно нещо - rsync и т.н. След като се качи новата версия в GAE, има админ панел, от който може да се избере, коя версия да е default и с едно цъкане може да се установи новата версия да е default и всички нови requests се припращат към нея. И тук идва и моята идея, че това не е нужно да става ръчно, а да си е автоматичен процес. Proxy сървъра или някакъв load balancer през който минават requests, да може да се конфигурира динамично от build scripta. Предполагам с някакъв специфичен post/get от някакъв адрес би могъл да заменя forwarding'a да е към друг сървър или към списък от други сървъри. 

С няколко модификации, предполагам, че подобен код може да се използва за proxy сървър.

http://www.google.com/codesearch/p?hl=en#z2mbzUiRsP8/trunk/emite-proxies/src/main/java/de/spieleck/servlets/ProxyServlet.java&q=ProxyServlet%20lang:java&sa=N&cd=4&ct=rc

Така ако имаме контрол върху самото proxy, може да се качи новата версия, да се провери дали работи с acceptance/end-to-end tests, след което да кажем на proxy сървъра да forward'ва requests към новата версия. Какво мислите за идеята ?

2010/7/31 Liubomir Petrov <liubomi...@gmail.com>

--
The human knowledge belongs to the world.

[Hristo Deshev]

Здравей, Миро,

2010/8/3 Miroslav Genov <mge...@gmail.com>

Преди малко попаднах на следния пост: http://agiletesting.blogspot.com/2010/08/what-automated-deploymentconfig-mgmt.html. Предполагам, че ще ви бъде интересен. 

Благодаря за линка. Някои от инструментите съм ги чувал, а другите ще ги прегледам

 

Относно deployment'a на java war файлове, ми се струва че един от възможните вариант е с custom proxy server, който може да се управлява.

И аз попаднах на идеята, да си криеш джава апп сървъра зад HTTP reverse proxy и даже намерих "рецепти" за нагласяне на nginx, който препраща трафика към примерно jetty или tomcat. Така можеш да вдигнеш втора инстанция на апп сървъра и после само да смениш конфигурацията на nginx. Сега трябва само да го пробвам и автоматизирам това нещо :-).

Христо

[Liubomir Petrov]

Здравей,
И аз като Христо, някой съм ги чувал, а останалите задължително ще ги прегледам :)
Проблема тук, не е толкова свързан с Continuous delivery-то, а повече в SPOF, които ще създадеш по този начин.
На теоргия звучи супер яко и иновативно (това което правят GAE), но на практика, се оказва, че това се е правило от години в уеб света - само че, не с custom server, ами с reverse proxy (nginx/apache/lighttpd/cherokee). В слуая, вместо GET/POST заявка, се изпълнява reload/restart или се handle-ва по някакъв специфичен начин от самия сървър.
Това относно версиите, също се прави, дори в примера които дадох преди ден-два-три, ползвам Mercurial за да тагва различни версии и чрез фабрик деплойвам/тествам/рестартвам. Ако нещо бъгне, с 1 команда (през фабрик) връщам старата версия и готово :)

Идеята за къстъм прокси сървър, има един плюс пред стандартните решения - може да се покдара автоматично намиране на сървърите по мрежата и според различни критерии да се вдигат като "master" / "child" и т.н. Добрата новина е, че има такова нещо:
http://hadoop.apache.org/zookeeper/ (кефете се, на java e (dull)).
Чрез zookeeper, според мен ще можеш да вържеш всички сървиси, чрез observer-и и да управляваш цялата ти система, без значение колко е голяма. А даже по спомен, ако си направиш и мрежа (може и vpn) м/у машините, ще подкараш и zeroconf (чрез P2P/UDP хакерлъците в zookeeper).
По този начин, можеш да имаш няколко N+1 проксита и N+1 сървиса отдолу, групирани според предназначението им :)

Доста е дълга темата и винаги ще имаш SPOF, поне аз не мога още да го измисля (може би понеже още не ми е потрябвало), но по-натам ще ми трябва и мисля да седна да си напиша такава архитектура (основно python/java). Ако случайно решиш, да ползваш ZooKeeper или измислиш друг начин за решаване на SPOF проблема, ще се радвам да споделиш :)


Поздрави,
Любомир Петров
Founder of Bizz.bg
Mobile: +359 897 994 386
E-Mail: lpe...@mylo.bg and lpe...@bizz.bg
E-Commerce Software as a Service: http://www.Bizz.bg/

2010/8/3 Hristo Deshev <hri...@deshev.com>

[Nikolay Bachiyski]

2010/7/31 Hristo Deshev <hri...@deshev.com>:

> Днес я мярнах в блога на Мартин
> Фаулър: http://martinfowler.com/snips/201007301801.html
> Книгата определено изглежда интересна, но не мога да намеря никъде
> съдържание. Чудя се доколко се концентрира на принципите на постоянния
> деплоймънт и доколко съдържа конкретни съвети за определени платформи.

Съдържание има тук: http://www.informit.com/store/product.aspx?isbn=0321601912

(цъкнете на Sample Content)

На същата страница можеш и да су купиш PDF за $35.99.

Н.