Projekt deaktivieren

[lmrkavogt]

Welches Problem möchtest du lösen? Wann tritt es auf? In der Entwicklung nutzen wir in der Regel eine App "dev", im Livebetrieb die App "live". Die App "dev" bleibt auch nach Live-Gang aktiv, taucht in Statistiken auf, wird nach Updates durchsucht und kostet Ressourcen.

Welche Lösungsideen hast du? Eine Möglichkeit schaffen, Apps zu deaktivieren und damit Ressourcen einzusparen. Die Apps werden "stillgelegt", sind also weder von extern aufrufbar noch im mStudio bearbeitbar, bis sie wieder aktiviert wird.

[patrickhilker]

Heyho, wir stellen in kurzer Zeit unsere Architektur so um, dass keine Ressourcen mehr "pro App" verbraucht werden (außer dem Speicherplatz natürlich). Damit dürfte das vermutlich schon erledigt sein.

Die Anzeige von Updates kostet keine Ressourcen auf dem Space-Server/proSpace.

Welchen Hintergrund hat es, dass man deaktivierte Apps nicht bearbeiten kann? Was genau erreicht man damit?

Die Aufrufbarkeit der Apps kann ich nachvollziehen, weiß aber nicht, ob das ne coole Lösung ist. Ich hätte für solche Dev-Systeme eher eine Basic Auth o.ä. erwartet, die einfach immer aktiv ist. Wie siehst du das?

[lmrkavogt]

Moin @patrickhilker Wann erfolgt dann Ressourcenverbrauch? Nur bei tatsächlichem Zugriff?

[patrickhilker]

Die Apps teilen sich (soweit möglich) ihre Ressourcen.

(Habe oben noch ein paar Punkte ergänzt.)

[lmrkavogt]

Welchen Hintergrund hat es, dass man deaktivierte Apps nicht bearbeiten kann? Was genau erreicht man damit?

Hmm, an der Frage saß ich jetzt ein paar Minuten... Spontan wahrscheinlich keinen, maximal wenn man Kunden mehr einbinden möchte und ggf deaktivierte Apps vor diesen Schützen verstecken möchte? Zu wage, kann eher weg

Ich hätte für solche Dev-Systeme eher eine Basic Auth o.ä. erwartet, die einfach immer aktiv ist. Wie siehst du das?

Wäre ich auch einverstanden mit. Ich denke das Thema "Dev-Projekre" wird sicherlich nochmal ein großes werden, weil viel diskutiert. Wenn man hier dann einen Switch aktivieren kann mit "ja, aber nur mit Kennwort" wäre ich da völlig ok mit :)

[DaRe92]

Tatsächlich wäre es gut wenn es diese Funktion analog wie im bisherigen Kundencenter (Projekt deaktivieren) geben würde. Wir nutzen es aktuell auch dazu wenn Kunden wechseln/aufhören um den aktuellen Stand einzufrieren, gleichzeitig aber von außen nicht mehr erreichbar sein dürfen/sollen.

Nach einer Übergangsphase wird das Projekt dann erst gelöscht.

[patrickhilker]

Tatsächlich wäre es gut wenn es diese Funktion analog wie im bisherigen Kundencenter (Projekt deaktivieren) geben würde.

@DaRe92 magst du dazu ein eigenes Issue erstellen? Das sind, glaube ich, zwei grundverschiedene Themen, die jeweils unterschiedliche Lösungsansätze brauchen.

[DaRe92]

@patrickhilker ich sehe hier eig. keinen anderen Lösungsansatz.

Die Apps werden "stillgelegt", sind also weder von extern aufrufbar noch im mStudio bearbeitbar, bis sie wieder aktiviert wird.

Beschreibt ja eig. genau das was passieren soll. Das bearbeiten sperren ist zwar in meinem Use Case nicht unbedingt notwendig, aber auch nice-to-have.

[patrickhilker]

Beschreibt ja eig. genau das was passieren soll.

Das heißt, E-Mails, externer Zugriff auf Datenbanken oder der Zugriff per SSH spielen dabei für dich keine Rolle?

[DaRe92]

E-Mails habe ich gar nicht bedacht. Allerdings liegen diese ja eh auf Projektebene. Somit hängen diese ja mehr an der Domain als an der App. Also sobald die Domain weg ist, ist auch der Zugriff auf die E-Mails nicht mehr. Das passt soweit und kann denk ich ignoriert werden.

DB Zugriff und SSH Zugriff sollten natürlich auch mit gesperrt sein. Dürfte aber auch im Anliegen des ursprünglichen Feature Requestes Erstellers sein.

[DaRe92]

@patrickhilker darf ich kurz nachfragen warum der Titel jetzt auf Projekt deaktivieren geändert wurde? Der Ersteller und ich haben ja explizit von App gesprochen.

[patrickhilker]

darf ich kurz nachfragen warum der Titel jetzt auf Projekt deaktivieren geändert wurde? Der Ersteller und ich haben ja explizit von App gesprochen.

Für mich klang es so, als würde sich der Request eher auf das ganze Projekt und weniger auf eine bestimmte App abzielen. Zumindest ist mir noch nicht klar geworden, wofür man das "App deaktivieren" braucht, das Projekt aber weiter aktiviert bleiben soll. Hast du vielleicht einen Anwendungsfall, der das ganz gut beschreibt?

[DaRe92]

Wir nutzen es aktuell auch dazu wenn Kunden wechseln/aufhören um den aktuellen Stand einzufrieren, gleichzeitig aber von außen nicht mehr erreichbar sein dürfen/sollen.

In dem von mir genannten Fall zum Beispiel um die Webseite erstmal abzuschalten, aber mit dem aktuellen Stand einzufrieren. Die Domain/Mail die ja auf Projektebene ist könnte aber noch bestehen bleiben weil zum Beispiel die Domain noch nicht übernommen wurde oder noch Laufzeit hat.

Oder wie vom Request Ersteller angedacht um die DEV Umgebung zu deaktivieren, aber ggf. schnell wieder Einsatzbereit zu haben.

[patrickhilker]

Es ist mittlerweile möglich, einer Domain "kein Ziel" zuzuweisen. Damit sollte ein Teil dieses Requests erfüllt sein, oder?

SSH-Zugänge, Datenbank-User und E-Mail-Adressen können natürlich schon gelöscht bzw. das Passwort geändert werden. Cronjobs können deaktiviert werden. Das zu vereinfachen wäre vermutlich weiterhin ein Wunsch?

[DaRe92]

Genau. Kein Ziel ist schon mal ein Workaround dafür.

Zum Thema vereinfachen: Es geht ja eig. wenig darum die Zugänge zu löschen. Es geht eher um das deaktivieren. Sonst müsste man beim reaktivieren ja alle Zugänge wieder anlegen.

[david-zacharias]

Wir hätten auch Interesse an dieser Funktion (der ursprünglich gewünschten: Das deaktivieren von Apps). Ein Anwendungsfall bei uns wäre das deaktivieren von Staging Systemen. Die man aber zu einem späteren Zeitpunkt wieder reaktivieren will - beispielsweise weil die Arbeit am Projekt wieder aufgenommen wird.