[git] Naast develop & master een staging branch?

[TheNephilim]

Voor een website waar ik aan werk wil ik graag een staging omgeving neerzetten. Normaal gesproken niet zo'n bijzonderheid, maar we hosten bij fortrabbit.com (zelfde idee als Heroku). Dat werkt dus net even anders.

Situatie

- develop/master branches (git flow met SourceTree).
- master gaat nu naar productie (bijv. app.eu01.fortrabbit.com).
- staging app al aangemaakt (bijv. app-staging.eu01.fortrabbit.com).
- master word altijd gebruikt door app, dus je kunt niet wisselen naar develop oid.

Mijn idee

Om een nieuwe branch aan te maken, genaamd 'staging' die als master gedeployed word naar die app-staging. Dan kan ik ontwikkelen in develop, als dat klaar is naar staging en als klant akkoord is naar master (productie).

Dat zou er zo uit moeten zien:

- develop
- develop -> staging (remote app-staging.master)
- staging -> master (remote app.master)

Maar...

Ik kan niet echt wat wijs worden uit http://help.fortrabbit.com/multi-staging. Daarnaast vraag ik me af of dat invloed heeft op git flow.

Kortom; staging branch naar remote master A en master branch naar remote master B. Kan dat zo?

[ Voor 6% gewijzigd door TheNephilim op 14-10-2015 14:34 ]

[H!GHGuY]

Alles kan


Het belangrijkste wat je van git-usage moet weten is dat je altijd je workflow in git moet zetten. Dus als je development -> staging -> master hebt als workflow, dan zet je dat dus ook best zo in branches.
Hou wel altijd rekening met een aantal aspecten over hoe je werkt:
- waar wordt actief op ontwikkeld? topic branches, development branch, ...
- waar worden fixes in het systeem gestopt? development, staging? beide?
- indien antwoord op bovenstaande staging/beide was: hoe vloeien die fixes terug naar development? Merge of cherry-pick? Of heb je toch nog een aparte branch nodig?

Dus: zoek de actoren (developers, testers, deploymers, ...), bepaal welke zaken ze willen doen (features, fixes, configuratie, ...) en hoe code tussen beide groepen heen en weer gaat. Hou rekening met de business (time-releases of feature-releases of continuous deployment) en eventuele andere wensen (merge of rebase strategie, ...).
Giet dat dan in een schema/model die de reëele flow van code weergeeft en plak daar repositories/branches op. Implementeer, geniet.

Wat je hierboven beschrijft is ook gewoon relatief common in CI/CD. Een build wordt gepromoveerd van development naar staging als hij een hoop testen doorstaat en promoveert zo verder door het systeem tot je bij de klant terecht komt.

[ Voor 9% gewijzigd door H!GHGuY op 14-10-2015 19:48 ]

[Megamind]

Als je toch git flow gebruikt gebruik dan releases.
http://nvie.com/img/[e-mail]

Release branch naar staging, en als die klaar is voor productie staging promoveren naar live en de release naar master mergen.

[Xudonax]

Wat Megamind zegt doen we bij mij op werk inderdaad ook, develop op lokaal en interne testserver (indien aanwezig), release gaat naar test/acceptatie omgeving (sommige klanten hebben meerdere test/acceptatie omgevingen) en vervolgens gaat release naar productie waarna de branch in master en develop gemerged word. Dit alles natuurlijk netjes met behulp van git-flow

[Matis]

Wij gebruiken daar een release of master-next branch voor.
Wanneer die volwassen is, gaat ie naar master en wordt getagged als release.

[TheNephilim]

Het staging plaatje is voor mij wel redelijk duidelijk denk ik, maar hoe ik die staging branch naar een remote -> master krijg wat minder

Over het algemeen is het meestal ontwikkelen in develop en af en toe mergen naar master. Feature branches zullen later wel gebruikt worden, als ik bepaalde onderdelen onafhankelijk zal moeten aanpassen. Nu is het nog vooral een preview voor de klant en er veranderd nog heel veel. Met release branches heb ik eigenlijk nog niet zoveel gedaan eerlijk gezegd.

Volgens mij kan ik dus gewoon een staging branch maken vanaf develop, die pushen (met SourceTree) naar een bepaalde remote (niet origin) master?

[mbarie]

Dat kan, mocht je een build tool hebben kan je natuurlijk ook gewoon naar de staging branch pushen op origin en dan wordt deze bij succesvol bouwen automatisch gepushed naar je staging environment.

[TheNephilim]

mbarie schreef op donderdag 15 oktober 2015 @ 10:45:
Dat kan, mocht je een build tool hebben kan je natuurlijk ook gewoon naar de staging branch pushen op origin en dan wordt deze bij succesvol bouwen automatisch gepushed naar je staging environment.

Haha, nee het is maar 'gewoon' PHP, dus geen build tools in da house

[mbarie]

Hier ook hoor, maar genoeg te 'bouwen' . Iets met enterprisey.

[TheNephilim]

mbarie schreef op donderdag 15 oktober 2015 @ 10:51:
Hier ook hoor, maar genoeg te 'bouwen' . Iets met enterprisey.

Zo ver ben ik nog niet, wie weet ooit eens. Naast eenvoudige bedrijfswebsites nu langzamerhand ook met wat applicatie-achtige dingen aan de slag. Leuke uitdaging!

[Hydra]

TheNephilim schreef op donderdag 15 oktober 2015 @ 10:38:
Het staging plaatje is voor mij wel redelijk duidelijk denk ik, maar hoe ik die staging branch naar een remote -> master krijg wat minder

Niet?

Je remote is een kopie van je repo. Je moet op staging dus gewoon release builds pakken en niet gaan proberen dit naar de master te zetten.

[TheNephilim]

Hydra schreef op donderdag 15 oktober 2015 @ 12:05:
[...]


Niet?

Je remote is een kopie van je repo. Je moet op staging dus gewoon release builds pakken en niet gaan proberen dit naar de master te zetten.

Nou dat is het dus, bij fortrabbit kun je alleen een app deployen naar een master branch. develop heb ik hier lokaal om te ontwikkelen, staging wil ik graag laten zien aan de klant en master staat online (productie).

Bij fortrabbit heb ik nu 2 apps. 'app' en 'app-staging', om een nieuwe versie online te zetten push ik naar '[e-mail]:app.git' en om de klant iets te kunnen laten zien in staging '[e-mail]:app-staging.git'.

Ik heb hier lokaal 3 branches;

- develop
- staging
- master

Die staging moet dus naar die fortrabbit staging remote, maar dan niet in de 'staging' branch, maar master. Volgens mij werkt dat gewoon: