Continuous Integration and Deployment

Fejlesztés

Sziasztok,

Szoftverfejlesztéshez kell telepítsek és konfiguráljak 'Continuous Integration'-t és 'Continuous Deployment'-et.
Ki milyen tool-okat és devops eszközöket használ a fentiek megvalósítására?

  • 4269 megtekintés

( uTibor | 2015. 10. 11., v – 22:18 )

Sokat segítene, ha elárulnád, hogy milyen technológiai stack-et használsz a fejlesztéshez.

En PHP-frontend stackre kovetkezoket hasznalok:

- composer betolti a build stacket, beleertve a nodejs-t, stb.
- phing vezerli a buildelest
- SASS foglalkozik a CSS-el
- uglify.js foglalkozik a JS-sel
- PHPUnit, PHPMD, PHPCS stb. eszkozok bekotve kodellenorzesre (bar a PHPCS egy kalap szar, a PHPStorm / TeamCity jobb lenne)
- Jenkins ellenoriz, buildel es deployol. Nem hasznalok kulon deployment eszkozt, mert mindegyik halal bugos es nehez testre szabni.
- Puppet gyartja a Jenkins configot.

Phing helyett hasznalhatsz Ant-et is, majdnem mindegy.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

A Jenkins SSH modulja ha jol tudom, rsync-el deployol, de van a latokoromben targz-s megoldas is. Minden esetben tortenik symlink atallitas, a live rendszer nginx-ei pedig ugy vannak felconfolva, hogy feloldjak a symlinket, szoval azonnal eletre lep a valtozas. Ezen felul meg az olyan projekteknel, ahol van adatbazis migratio (pl Doctrine Migrations), ott az is lefut scriptelve. (Vagy Jenkins SSH config, vagy phing.)

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

Egy par projektnel hasznalatban van a Capistrano, de sajnos idonkent eleg nehez debuggolni hogy miert nem akarja az igazat. Sokszor sokkal egyszerubb megirni a Jenkins SSH moduljaval shell scriptben mint a Cappel szivni.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

Na ja, de ha jól értelmezem, a kérdező itt most egy admin, aki feladatul kapott egy olyan rendszer kiépítését, amihez a fejlesztők aktív közreműködése kellene. Ez így picit céltalannak tűnik nekem.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Részben igen, elég furi figurák vannak. Viszont az üzemeltetés mint olyan az egy kicsit másik állatfaj. Nyilván cégprofilonként eltérő, hogy mennyire tudná magától megugrani egy normálisan kompetens dev csapat legalább a sw deploymentet, és mennyi olyan dolga van a "régi" (vagy inkább klasszikus) deployment / op-nak, amik nem egy development dolgai, de valamennyi mindig lesz.

Jó esetben van egy egymás kompetenciáját a szélein átfedő két társaság, meg akarat, hogy mehessen egy integrált folyamat, rossz esetben meg van egy hülye developer, aki tolja az éppen aktuális buzz deploymentet, dinoszauroszozza az infrás csapatot, hogy mostantól csak dugdossa a kábeleket, miközben egyébként kurvára hülye az egészhez; esetleg a másik oldalról van egy totálisan inflexibilis infra, aki ragaszkodik a 15 éve kialakult toolchainhez, meg a kéthónapra előre bebetonozott change windowhoz egy 2 perces, automatán rollbackelhető kód updatehez, aki nem érti, hogy miért rühelli mindenki ezt...

Össze kell ültetni egy légtérbe a fejlesztőt és az üzemeltetőt, hogy a fejlesztő lássa, mennyi szopásba kerül, ha nem veszi tekintetbe az üzemeltetési szempontokat és viszont, az üzemeltető is lássa, hogy mennyi szopásba kerül, ha nem veszi figyelembe a fejlesztők igényeit...

...csak így megy, ha reggel az üzemeltető kever le egy hatalmas tockost a fejlesztőknek, mert hajnalban felverte egy riasztás, vagy reggel a fejlesztő kever le egy hatalmas tockost az üzemeltetőknek, mert késő estig szopott...

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Hehe, valo igaz, bar nem is mindenkinel mukodik, szemelyisegfuggo."

Hajlok arra, hogy akivel ez nem működik, az nem képes csapatban dolgozni és jelenleg olyan az összes fejlesztési módszertan és üzemeltetési környezet, hogy csapatban KELL dolgozni...

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

+1

Az informatikusok szeretnek hőzöngeni, ha az első (azaz inkább nulladik, tbh) körös interjún a recruitert nem érdekli, hogy ő milyen penge szakmailag, csak a személyiségre kíváncsiak. Úgy tűnik, ennek is megvan az oka. :)

Programozni/üzemeltetni bárki meg tud tanulni (ofc ez is teljesítmény, nem mondtam, mennyi idő és energia kell hozzá), de csapatjátékost csinálni valakiből már nem egyszerű.

Nagyon sokat segít, bár ha észnél van a cég, akkor talán enélkül is lehet. Illetve inkább a másik oldalról közelítve, ha szervezetileg nincsenek közel egymáshoz, akkor az egy légtér is tud kevés lenni...

(Ill van még az, hogy fejlesztő nagyon nem szeret ügyelni, és ma a jó fejlesztő tud diktálni a cégnek)

Epp ma:

dev: Hangosan teker a ventilator a laptopomban.
en: He? Miota?
dev: blablablabla
en: Muti. Tenyleg. Hmm, init, meg ilyenek zabaljak a cpu-t, WTF!!?!?
en: tail -f /var/log/syslog, sajat termek service exit 1 -> upstart -> respawn
dev: Ez hogy, ez miez?
en: Te telepitetted.
dev: biztos..

:D

latod, milyen jo a kozos szoba? Csapni a kezere, amelyikkel lenyomta az entert, root/sudo jog elvesz... :-)
--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

( o_O v | 2015. 10. 11., v – 22:58 )

Eleg szeles tema kor es teljes out of box megoldas tutira nincs.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

( gee v | 2015. 10. 12., h – 00:56 )

Utoljára CI-re egy GNU make-re épülő megoldást.
Kódgenerálásra volt valami modul ami a C++ programot elkészítette a Rational Rose modellből.
Tesztek shell scriptben.

CD nem volt.

( atomheart v | 2015. 10. 12., h – 01:17 )

Hirtelen ez ugrott be, sztem egy paran raismertek: "It’s good because I made it for myself!" :^)

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

( shark | 2015. 10. 12., h – 07:32 )

Mi Javara Jenkins-t használunk. Folyamatosan futnak az funkcionális tesztek VMWare instance-eken minden build után, éjjelente pedig performance tesztek. Némely régi projekt anttal buildelődik, mások már Mavennel. Local repository-nak Sonatype Nexus-t, statikus kódelemzőnek SonarQube-ot használunk. A sprint végén egy job előállít egy installálható iso-t, ehhez viszont az kell, hogy minden zöld legyen pár napig. Ahhoz pedig, hogy rögtön látható legyen, hogy valami baj van, Jenkins alá van egy saját monitor pluginünk (szokták hívni lávalámpának is), ami megjeleníti a jobok státuszát egy TV-n a falon.

( mrmartin v | 2015. 10. 12., h – 08:55 )

ci.openstack.org itt érdemes körülnézned, zuul, jenkins, gerrit etc.

( _Franko_ v | 2015. 10. 12., h – 09:11 )

Milyen platformra és/vagy nyelvhez kell? Nagyon nem mindegy.

( hrgy84 | 2015. 10. 12., h – 11:54 )

Kezdjuk ott, hogy a projekted egyaltalan tartalmaz-e barmilyen deployment megoldast a jelenlegi formajaban? Vannak-e tesztek a projektben? Egyaltalan, a projekt megirasakor figyelembe lett-e veve a tesztelhetoseg, mint lehetoseg?

Amig ezekre a kerdesekre nem "Igen" a valasz, addig ne keresgelj semmit, hanem kezdd el atstrukturalni a kododat, ez le fog foglalni kb. negyed evre, utana gyere vissza, ird le, milyen megoldasokat alkalmaztok, hogyan epul fel a rendszer, es ajanlunk megoldasokat.

Bocs, de ez egy olyan terulet, amit nem csakannyal szokas piszkalni, hanem precizios vesovel.
--
Blog | @hron84
Üzemeltető macik

Én a következő megoldást használom PHP projekt esetén :
- Jenkins, Unit tesztek, egyéb környezet specifikus tesztek
- ha sikeresek voltak a tesztek a Jenkins-ből ssh-zok a deployment szerverre és egy shell szkript elvégzi a deploy-t.
A shell script biztonsági mentést készít, majd frissíti a kódot egy verzió kezelő rendszerből.
- végül küld egy emailt a fejlesztő csapatnak.

Érdekelne, hogy milyen más megoldások vannak.
Köszönöm előre is.

Nagyjabol ezt lehet meg jobban korbebastyazni. Ha pl. van production branch a kodban, akkor ahhoz is lehet Jenkins jobot kotni, ha valaki oda pushol, az kimegy elesben. Bitbucketen lehet branch vedelmet csinalni, hogy csak olyan pusholhasson a prod branchbe, akinek erre joga van (a BB-t hajto szoftver elerheto on-premise is, valami Atlassian termek, fejbol meg nem mondom, mi a neve).

A shell scriptek helyett nezzetek meg a Phinget es/vagy a Capistrano-t, eleg sokat tud segiteni.

Teszt VM-ek epitesehez jo lehet a Vagrant, az OS oldali fuggosegek kezelesehez Chef vagy Puppet.

Felulettesztekhez feltetlenul nezzetek meg a Seleniumot, ezt pl. a deployment szerver egyik elszeparalt vhostjan lehet futtatni, tortenik egy teszt deployment oda, utana lefut a Selenium, es kiad valamilyen eredmenyt. Ez a teszt vhost lehetoleg ne egyezzen meg a staging vhosttal, mert itt akar uzemkeptelen kod is lehet, illetve undefined state.

Generikusan ennyit tudok mondani, a sw behatobb ismerete nelkul konkret deploymentet tervezni nem lehet.

Ha elegedetlenek vagytok a Jenkinssel, vagy tul sok a szivas vele, nezzetek ra a JetBrains TeamCity nevu szoftverere, szinten CI szerver, de sokkal-sokkal okosabb a Jenkinsnel, es sokkal straightforwardabb a menedzsmentje. Sajnos fizetos szoftver, de van ingyenesen hasznalhato verzioja, mely 20 build konfiguraciot tamogat (Jenkins terminologia szerint jobot, de itt a jobokat projektekbe tudod szervezni).
--
Blog | @hron84
Üzemeltető macik

( zolo | 2015. 10. 12., h – 14:37 )

Nalunk .deb csomagok vannak, ennek a buildjet jenkins csinalja. Ha kesz, promote a megfelelo Debian repo-ba (int1/qa/live).

Puppet-et hasznalunk konfig- es csomagkezelesre. Jelenleg sajnos meg nem latest-et hasznalunk a csomagokra (App), hanem fix verziot.

( gelei v | 2015. 10. 12., h – 14:58 )

Nem biztos, hogy követendő példa (<-- eufémizmus), de dolgoztam olyan helyen, ahol a continuous deployment azt jelentette, hogy a szerveren futott a Visual Studio, és a build output mappája "véletlenül" pont megegyezett az IIS wwwroot-jával.

Never again. Olcsó és gyors "megoldás" volt, de elég stresszes. :)