Moin,
die momentane Situation bezüglich unseres Puppet-Entwicklungsworkflows stößt mir (und vermutlich auch anderen) etwas auf.
Wie sieht der momentane Weg aus, um im unseren Puppet was zu entwickeln?
- Auf dem Master im Production entwickeln - auf seinen Client kopieren - im git committen
Wait, what?
Warum machen wir das nicht "the bytemine way"? Ein dev-Branch, da entwickeln (und testen), dann per git commit ins production- Environment?
Grüße bjo
Moin,
für mich ist die größte Hürde, den ganzen Source local zu pushen. Hier müssen wir uns noch etwas überlegen
Ursprünglich hatten wir im Master entwickelt.
Spricht hier etwas dagegen?
Am 30. Juli 2016 09:47:12 MESZ, schrieb Bjoern Franke via Dev dev@lists.ffnw.de:
Moin,
die momentane Situation bezüglich unseres Puppet-Entwicklungsworkflows stößt mir (und vermutlich auch anderen) etwas auf.
Wie sieht der momentane Weg aus, um im unseren Puppet was zu entwickeln?
- Auf dem Master im Production entwickeln
- auf seinen Client kopieren
- im git committen
Wait, what?
Warum machen wir das nicht "the bytemine way"? Ein dev-Branch, da entwickeln (und testen), dann per git commit ins production- Environment?
Grüße bjo _______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Am Samstag, den 30.07.2016, 09:50 +0200 schrieb Stefan via Dev:
Moin,
für mich ist die größte Hürde, den ganzen Source local zu pushen. Hier müssen wir uns noch etwas überlegen
Ursprünglich hatten wir im Master entwickelt.
Spricht hier etwas dagegen?
Ja, zum Testen ist es schlecht.
Wenn wir zwei Environments hätten, könnte man beim Entwickeln auf einer Testnode "puppet agent -t --environment dev" durchlaufen lassen und bricken nicht ggf. die anderen Nodes.
grüße
Hi,
für mich ist die größte Hürde, den ganzen Source local zu pushen. Hier müssen wir uns noch etwas überlegen
Ursprünglich hatten wir im Master entwickelt.
Spricht hier etwas dagegen?
Ja, zum Testen ist es schlecht.
Wenn wir zwei Environments hätten, könnte man beim Entwickeln auf einer Testnode "puppet agent -t --environment dev" durchlaufen lassen und bricken nicht ggf. die anderen Nodes.
Clemens und ich hatten darüber schonmal gesprochen. https://git.nordwest.freifunk.net/ffnw-puppet/puppet
Eine weitere idee war einen stable branch zu haben und master == dev. Somit kann man fertige Master zustände einfach merge oder einzelene änderungen cerry-picken. oder eben auf stable einen neune branch aufmachen also z.B. v1.42 gewünschte änderunge aus dem Master in den branch stecken und dann ganze in stable mergen. Das macht es eigentlich relativ bequem.
vg Tarek
Moin
Am 30.07.2016 um 09:50 schrieb Stefan via Dev dev@lists.ffnw.de:
Moin,
für mich ist die größte Hürde, den ganzen Source local zu pushen. Hier müssen wir uns noch etwas überlegen
Das ist ein Anwender Problem das man lösen kann ;)
Ursprünglich hatten wir im Master entwickelt.
Spricht hier etwas dagegen?
Bis zum ersten Release kann man das machen danach stimme ich Björn zu, das ihr einen Development Branch macht. bzw überhaupt ein Branching Konzept macht. bei Bedarf kann ich da gerne mal ein paar Möglichkeiten mal zeigen.
Am 30. Juli 2016 09:47:12 MESZ, schrieb Bjoern Franke via Dev dev@lists.ffnw.de:
Moin,
die momentane Situation bezüglich unseres Puppet-Entwicklungsworkflows stößt mir (und vermutlich auch anderen) etwas auf.
Wie sieht der momentane Weg aus, um im unseren Puppet was zu entwickeln?
- Auf dem Master im Production entwickeln
- auf seinen Client kopieren
- im git committen
Wait, what?
Warum machen wir das nicht "the bytemine way"? Ein dev-Branch, da entwickeln (und testen), dann per git commit ins production- Environment?
Grüße bjo
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
-- vg Stefan _______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Gruß
Johannes
Moin,
wir können gerne ein DEV Environment einrichten, ich habe da kein Problem mit :)
Ich meinte eben folgendes: Die Server werden via production deployed und im Master war der Dev Teil.
Am 30. Juli 2016 10:05:25 MESZ, schrieb Johannes Rudolph via Dev dev@lists.ffnw.de:
Moin
Am 30.07.2016 um 09:50 schrieb Stefan via Dev dev@lists.ffnw.de:
Moin,
für mich ist die größte Hürde, den ganzen Source local zu pushen.
Hier müssen wir uns noch etwas überlegen Das ist ein Anwender Problem das man lösen kann ;)
Ursprünglich hatten wir im Master entwickelt.
Spricht hier etwas dagegen?
Bis zum ersten Release kann man das machen danach stimme ich Björn zu, das ihr einen Development Branch macht. bzw überhaupt ein Branching Konzept macht. bei Bedarf kann ich da gerne mal ein paar Möglichkeiten mal zeigen.
Am 30. Juli 2016 09:47:12 MESZ, schrieb Bjoern Franke via Dev
Moin,
die momentane Situation bezüglich unseres
Puppet-Entwicklungsworkflows
stößt mir (und vermutlich auch anderen) etwas auf.
Wie sieht der momentane Weg aus, um im unseren Puppet was zu entwickeln?
- Auf dem Master im Production entwickeln
- auf seinen Client kopieren
- im git committen
Wait, what?
Warum machen wir das nicht "the bytemine way"? Ein dev-Branch, da entwickeln (und testen), dann per git commit ins production- Environment?
Grüße bjo
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
-- vg Stefan _______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Gruß
Johannes
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
-
Bjoern Franke -
Jan-Tarek Butt -
Johannes Rudolph -
Stefan