NEWS
Staging Testsystem --> Prodsystem
-
Moin,
ich will mir nicht immer das Prodsystem beim probieren "zerspielen", daher habe ich mir jetzt ein Testsystem gebaut.
Wir kann ich dinge einfach von Test nach Prod kopieren. Manuell ist das dann doch ziemlich aufwändig. Wie macht ihr das? -
@dlaurenz sagte in Staging Testsystem --> Prodsystem:
Manuell ist das dann doch ziemlich aufwändig
Und genau so macht man das.
Wenn im Testsystem was passt dann muss man halt Hand anlegen und das Passende in das Prod einfügen. Oder was erwartest Du ? Ein smartes Testsystem welches Gedanken liest und diese dann ins Prod beamt ? -
@dlaurenz sagte in Staging Testsystem --> Prodsystem:
Wie macht ihr das?
Moin,
laut Radio Eriwan, das kommt darauf an, was Du wie, wo laufen hast?
Also ich habe Proxmox, da Klone ich einfach meinen
ioBroker
LX Container, dann probiere ich die Änderungen/Anpassungen aus, und mache anschließend genau das gleiche, im Produktivsystem. Dann lösche ich den Klon wieder.
Es ist auch interessant, was Du kopieren willst, wenn esioBroker
interne Sachen sind, dann geht das mit kopieren nicht, sind das aber Textdateien, z. B. Konfigurationsdateien von Programmen, dann kann man sich Git installieren oder GitHub nutzen, dann geht das dann darüber, Du passt eine Datei an, sicherst die in GIT und holst die Änderung dann ins Produktivsystem.Es kommt ja auch darauf an, was Du Dir da immer wieder
zerspielst
?VG
BerndP.S.: Ich denke, dass Du mit einer sauberen Backupstrategie, besser fährst, min. vor Veränderungen am
ioBroker
einBackitUp
Backup machen, da Du nicht erwähnt hast wo Dein System drauf Läuft, kann ich zum Vollbackup der gesamten Installation nichts sagen. -
@dlaurenz sagte in Staging Testsystem --> Prodsystem:
Manuell ist das dann doch ziemlich aufwändig
Was zerpsielst du dir denn da? Wenn du eine neue Adapterversion im Testsystem ausprobierst und alles ist gut, dann kannst du den Adapter doch genauso im Prod-System installieren, kein großer Aufwand.
Wenn es um Skripte geht kannst du die doch per copy&paste rüberkopieren.Gib mal konkrete Beispiele, was dein Problem ist.
-
@amg_666
Also bei größeren Release Sprüngen würd ich auch eher mal testen.
Falls der neue Adapter etwas anders macht und evtl Daten transformiert. Dann macht der alte Adapter bei downgrade das nicht rückgängig.
Bei jscontroller erst recht (auf jeden Fall bei Major, ggfs bei Minor Release Wechsel. Bei Patch muss man nicht.
Weiß aber nicht ob man hier semantic versioning durchhält und alle Adapter Entwickler da den Unterschied kennen. -
@oliverio sagte in Staging Testsystem --> Prodsystem:
Also bei größeren Release Sprüngen würd ich auch eher mal testen.
Moin,
das sind aber alles Änderungen, wo man nichts Kopieren kann, das muss man im Produktivsystem dann 1:1 genauso durchspielen, wie auf der Testmaschine.
Und ja, ich bin zu 100 % bei Dir!VG
Bernd -
@dp20eic So sehe ich das auch, ich kann da keinen hohen manuellen Aufwand sehen...
-
nun es geht mir eher um dinge wie vis / datenpunkte / skript programmierungen / ggf. sogar noch mit darunter liegenden shell skripten... weniger die adapter, das man da nicht viel machen kann, ist mir klar
-
@dlaurenz sagte in Staging Testsystem --> Prodsystem:
nun es geht mir eher um dinge wie vis / datenpunkte / skript programmierungen / ggf. sogar noch mit darunter liegenden shell skripten... weniger die adapter, das man da nicht viel machen kann, ist mir klar
Moin,
na ja, so hattest Du das im ersten Post halt nicht formuliert, dass dann alle anfangen zu spekulieren ist ja ganz normal
Zu Skripten, ich habe mir
Visusl Studio Code
installiert, da gibt es ein Plugin fürioBroker
und intern GIT, damit kannst DuJS
super komfortable Schreiben und auf die Kisten deployen, durch GIT ist dann auch ein zurück einfach möglich, Versionskontrolle, schau mal bei @haus-automatisierung -> https://www.youtube.com/watch?v=5E9BGYMbxS4 vorbei, da siehst Du wie man es einrichten kann.VIS geht doch über Projekt Export / Import, ob man da dann in den Dateien von Hand herummachen kann, kann ich nicht sagen, da ich VIS nicht nutze.
VG
Bernd -
@dp20eic sagte in Staging Testsystem --> Prodsystem:
Also ich habe Proxmox, da Klone ich einfach meinen ioBroker LX Container, dann probiere ich die Änderungen/Anpassungen aus, und mache anschließend genau das gleiche, im Produktivsystem. Dann lösche ich den Klon wieder.
ja geht aber nur bedingt bei anderen..
bei mir geht es garnicht.. da ich eine redis Sentinel nutze und somit landet dann alles in Prod..
also vorsicht...
auch mit Backup ist das nicht möglich... da alles direkt in redis landet und dierkt auf 5 nodes ...
-
@arteck sagte in Staging Testsystem --> Prodsystem:
bei mir geht es garnicht.. da ich eine redis Sentinel nutze und somit landet dann alles in Prod..
also vorsicht...
auch mit Backup ist das nicht möglich... da alles direkt in redis landet und dierkt auf 5 nodes ...Moin,
ja, aber wenn man ein so ausgeklügeltes System unterhält, dann kommt man auch nicht auf so eine Idee, wie eingangs vom TE formuliert
Was
Redis
angeht, kenne ich das nur ein wenig von der Arbeit, sind/waren aber andere Kollegen die das Administriert haben. Ich werde, sollte jemals meine Hardware, doch noch zu mir kommen, ist von Kickstarter, dann versuche ich auch zu zentralisieren,mqtt - Broker
,Redis
, Datenbank Cluster (Postgres, MariaDB, InfluxDB), usw.VG
Bernd -
@dp20eic ja dagebei ixh dir recht... einfach so funktioneirt es nicht
und...
lass die Finger von Zentrallisierung.. mehrere System sind zwar pflegeintesiver aber wenn was ist dann ist nur ein Teil weg und nicht ALLES..bin kein Freund von..
-
@arteck sagte in Staging Testsystem --> Prodsystem:
lass die Finger von Zentrallisierung.. mehrere System sind zwar pflegeintesiver
Moin,
ich meinte, immer Cluster, ein dritter kommt dann später noch dazu
Proxmox Cluster Node 1 Node 2 Master Dienst Applikation my_emqx_1 my_emqx_2 mqtt broker emqx my_postgres_1 my_postgres_2 Datenbank Postgres Postgres my_mariaDB_1 my_mariaDB_2 Datenbank mariaDB mariaDB my_influxDB_1 my_influxDB_2 Datenbank influxDB
influxDB
>=V2my_ioBroker_prod ioBroker
produktivioBroker
my_ioBroker_test ioBroker
TestioBroker
my_Grafana Dashboard/Visualisierung Grafana
Grafana
my_Loki Logging Loki my_paperless_ngx Dokumentenverwaltung paperless-ngx Bei
Redis
muss ich noch schauen, ob ich klassisch HA mache oderSentinel
Tendenz geht zu letzterem.@arteck sagte in Staging Testsystem --> Prodsystem:
aber wenn was ist dann ist nur ein Teil weg und nicht ALLES..
Durch das Cluster sollte ich ja da dann bei
Single Point of Failure
geschützt sein, dazu gehört dann natürlich auch noch eine Backupstrategie, die ich mittels Proxmox - PBS und Syno löse.VG
Bernd -
@dp20eic jetzt würden wir aber das Thema hier sprengen....
back to ....xxx
-
@arteck nö macht mal weiter.... ist interessant
-
@dlaurenz sie meinen ??