[pitu-pr]

Chciałbym usprawnić pracę nad projektem. Posiadam repo, na lokalu skonfigurowanego vagranta z puphetem. W razie stawiania projektu lokalnie jednym klikiem stawia mi się wszystko.

Teraz przydałoby mi się coś podobnego ale na "produkcji". Np. aby z gita pobrało branch master, odpaliło composera + ew. moje komendy.

Ktoś coś?

[G.....n]

@pitu-pr: Najprostszy skrypt w bashu.

[Speedy]

@pitu-pr: O Jenkinsie słyszałeś?

[k.....o]

@pitu-pr: capifony capistrano ansible bash ant bamboo jenkins

[wrzes]

@pitu-pr: Ja używam Rocketeer, w sumie dla Laravela i trzeba trochę pokonfigurować, ale robotę robi. Gdzieś tam przy łoterkulerze przewinęły się też nazwy Deployer i Magallanes, ale nie używałem. Za to capifonycwel, bo nigdy mi się nie udało zmusić do działania.

[G.....n]

@wrzes: @kmicolo: @Speedy: Pytanie brzmi - po cholerę tyle narzędzi, by odpalić 10 komend w shellu?

[k.....o]

@Ginden: jak deployujesz wordpressa na wirtualke, to starczy rsync. Gorzej kiedy robisz cos powaznego, nagle CI i system deployowania który ogarnie zaawansowane operacje, zmiany konfiguracji, migracje itd. staje sie niezbedny.

[G.....n]

@kmicolo: Jak masz jakiś niewyobrażalnie skomplikowany projekt, który instalujesz codziennie na innym serwerze - to tak. Tylko, że ~95% użytkowników tego typu narzędzi takich projektów nie ma, a instalację można przeprowadzić w 20 linijkach basha. A jeśli nie mogą tego zrobić - to robią coś źle.

Kompilacją kernela Linuxa nie zarządza Capifony, Capistrano, Ansible, Ant, Bamboo czy Jenkins, ale zwykły

make

- i on jest wystarczający dla niemal każdego developera.

Ja

[k.....o]

@Ginden: laravela i wordpressa mozesz tak deployowac. Kiedy w gre wchodzi tylko glupi composer juz jest problem z takim kilkulinijkowcem. No i nie powie on nawet czy deploy sie udal.

[G.....n]

No i nie powie on nawet czy deploy sie udal.

@kmicolo: Pytanie dnia - czemu deploy, w którym żadna z komend nie zwróciła błędu, miałby się nie udać?

Kiedy w gre wchodzi tylko glupi composer juz jest problem z takim kilkulinijkowcem

Composer od połowy 2013 zwraca kod błędu jak wystąpi błąd.

[k.....o]

@Ginden: kiedy sprawdzasz kody bledow to ten bashscript sie rozrasta i nagle lepien uzyc jakiegos narzedzia ktore takie rzeczy ogarnia out of box :) np. taki ant, idealny do prostych deployow. Konfigurujesz xmla, budujesz projekt i deployujesz rsynciem.

[G.....n]

@kmicolo:

kiedy sprawdzasz kody bledow to ten bashscript sie rozrasta

O całą linijkę. xD

Rozumiem, że jak masz coś skomplikowanego czy kilkadziesiąt osób pracujących nad projektem to w porządku - trzeba coś przenośnego i łatwego w użyciu, co zadziała pod każdym systemem - to normalne. Ale wątpię, czy choćby 20% programistów PHP pracuje w teamach, w których problem z deployem występuje częściej niż raz na pół roku.

[Speedy]

@Ginden: Nie każdy ma dostęp do shella. Poza tym, gdy mamy takiego Jenkinsa, to nawet osoba nietechniczna może zrobić deploy jednym klikiem. Ponadto, gdy chcemy rozszerzyć konfigurację lub dodać jakieś dodatkowe zadania, jest to proste i nie musimy rozbudowywać skryptu shellowego lub za każdym razem logować się na wirtualkę i wklepywać kilkanaście komend. Możemy też niektóre zadania łatwo zautomatyzować. Np. robić builda po każdym commicie na mastera. W shellu też się

[G.....n]

robić builda po każdym commicie na mastera. W shellu też się pewnie da, ale więcej z tym roboty.

@Speedy: To są podstawy gita, sorry. http://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks

[wrzes]

Pytanie brzmi - po cholerę tyle narzędzi, by odpalić 10 komend w shellu

@Ginden: Narzędzie jest jedno i wybierasz sobie takie, które ci najbardziej pasuje.

A po cholerę? Po to żeby zamiast 10 komend odpalać jedną (lub jeden plik). Pomijam już kwestię tego, że soft jest na kilku serwerach, nie każdy ogarnia shella, a i przywracanie poprzednich wersji oraz migracje bazy są krytycznie istotne.

[Speedy]

@Ginden: A w czym przeszkadza zrobienie hooka na build na Jenkisie? Masz wtedy elegancką historię, output z konsoli, etc. Można robić build bez Jenkinsa, ale dogrzeb się później do informacji o błędzie lub wyślij maila lub wykonaj dowolną akcję, gdy build zostanie popsuty. Powodzenia ze skrypcikami. Zaskryptujesz się na śmierć. ( ͡° ͜ʖ ͡°)

[k.....o]

@Ginden: rob builda w shellu. To moze bytecodem na kartach perforowamych? I nie jedna, a conajmniej dwie linijki. Zamiast kodów błędów raczej się wyłapuje z outputu warningi i errory w praktyce. No i zamiast tego skryptu wolalbym juz rsynca odpalac z palca :) kiedys widzialem deploy script w pythonie. Tez zaczelo sie od kilku linijek, skonczylo na okolo 800. 800 linijek bukake builda. Kazdy dal cos od siebie, nie kazdy znal

[G.....n]

A po cholerę? Po to żeby zamiast 10 komend odpalać jedną (lub jeden plik).

@wrzes: Pliki

.sh

, polecam.

nie każdy ogarnia shella

To smutne, że ludzie nie ogarniają podstawowego narzędzia pracy na minimalnym choćby poziomie.

soft jest na kilku serwerach

Shell działa podobnie na wszystkich Linuxach, jeśli korzystacie zarówno z Windowsa jak i Linuxa, to rzeczywiście, dedykowane narzędzie będzie lepsze.

przywracanie poprzednich wersji

Od tego masz Gita.

migracje bazy są

[k.....o]

@Ginden: bo po to sa. Wole uzywac dedykowanych narzedzi, niz wymyslac kolo na nowo.