Dieser Artikel ist auch verfügbar in:
Wir unterscheiden drei Arten von Änderungen: Bugs, Features und Infrastruktur- oder Systemwartungsänderungen. Die Anfangsphase ist für jede Änderung anders, aber sie haben alle den gleichen Entwicklungs-, Test- und Bereitstellungsprozess.

Vom Kunden gemeldete Bugs
Wann immer ein Fehler an unseren Kundenservice gemeldet wird, wird dieser Fehler in unserem internen Service Desk gemeldet. Vom internen Service Desk aus wird der Fehler durch das QA-Team validiert. Gültige Bugs werden dann an unser devsupport1-Team eskaliert, das sich um Bugs kümmert. Von diesem Moment an folgen sie demselben Entwicklungsprozess wie neue Funktionen.

Funktionen
Features aus der Roadmap, die für die Entwicklung ausgewählt werden, werden vom Produktmanager in Akzeptanzkriterien festgehalten. Bevor das Feature implementiert wird, wird es von allen beteiligten Teams diskutiert und verfeinert.

Infrastruktur- und/oder Systemwartung
Es gibt verschiedene Gründe, die eine Änderung in der Infrastruktur/dem System verursachen.

Es gibt Sicherheitsupdates für Software von Drittanbietern, von der unser Produkt abhängt.
Es gibt neue Versionen für Software von Drittanbietern, von der unser Produkt abhängt.
Änderungen in der Infrastruktur/im System sind erforderlich, um unser Produkt oder unsere Arbeitsabläufe zu verbessern.

Diese Änderungen, die für die Entwicklung ausgewählt werden, werden dann von unserem Entwicklungsteam besprochen und dann implementiert, so wie es auch bei Features gemacht wird. Angesichts unserer Politik der sicheren Entwicklung geben wir Sicherheitsupdates Vorrang.

Entwicklungsprozess
Der Prozess hat die folgenden Stufen:

Diskussion: Die Akzeptanzkriterien werden für die beabsichtigte Änderung ausgeschrieben/verbessert. Dadurch wird sichergestellt, dass jeder, der an dem Feature/der Änderung arbeitet, weiß, was das beabsichtigte Endergebnis ist. Es wird angestrebt, viele kleine Verbesserungen gegenüber großen Änderungen vorzunehmen.
Entwicklung: Mindestens zwei Entwickler arbeiten am Code. Wir verwenden testgetriebene Entwicklung. Wir testen unseren Code mit automatisierten Unit-, Integrations-, Funktions- und Akzeptanztests. Alle neuen und bestehenden Tests müssen bestanden werden, bevor der Schritt der Codeüberprüfung erfolgt.
Code-Review: Alle Änderungen werden von mindestens einem anderen Entwickler überprüft, der nicht an dem Code gearbeitet hat. Hier überprüfen wir, ob der Code den Standards entspricht. Wir verwenden die OWASP top102, um auf Schwachstellen zu prüfen. Die Änderung kann erst in die nächste Phase übergehen, wenn alle Rückmeldungen geklärt sind und alle Codeänderungen erneut überprüft wurden.
Qualitätssicherung: Die Änderungen werden vom QA-Team getestet. Wenn die Änderungen die Akzeptanzkriterien oder die Zugänglichkeitsstandards nicht erfüllen oder andere Probleme aufweisen, kehrt der gesamte Prozess in die Entwicklungsphase zurück.
Zusammenführen: Alle Änderungen werden in die Entwicklungsversion des Produkts eingefügt.
Freigabe: Wir geben täglich eine neue Version unserer Software frei:
Wir stellen die neueste Entwicklungsversion auf unsere Staging-Umgebung zum Testen.
Wir führen den Abnahmetest für die gesamte Anwendung durch.
Wenn alles bestanden ist, werden alle Änderungen in die Produktion übernommen.

Hinweise
Das Devsupport-Team ist ein Team von Entwicklern, das bei der Unterstützung unseres Produkts hilft. Die meisten unserer Bugs werden von diesem Team gelöst.
Die OWASP-Top10 ist eine Liste der häufigsten Sicherheitslücken. Eine Liste kann auf der OWASP-Website gefunden werden: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
War dieser Beitrag hilfreich?
Stornieren
Danke!