Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[amg_666]

@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.

[OliverIO]

@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.

[Ein ehemaliger Benutzer]

@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

[amg_666]

@dp20eic So sehe ich das auch, ich kann da keinen hohen manuellen Aufwand sehen...

[DLaurenz]

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

[Ein ehemaliger Benutzer]

@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ür ioBroker und intern GIT, damit kannst Du JS 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

[arteck]

@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 ...

[Ein ehemaliger Benutzer]

@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

[arteck]

@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..

[Ein ehemaliger Benutzer]

@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 >=V2
my_ioBroker_prod			ioBroker produktiv	ioBroker
	my_ioBroker_test		ioBroker Test	ioBroker
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 oder Sentinel 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

[arteck]

@dp20eic jetzt würden wir aber das Thema hier sprengen....

back to ....xxx

[DLaurenz]

@arteck nö macht mal weiter.... ist interessant

[arteck]

@dlaurenz sie meinen ??