Bitrix24
Bitrix24 On-Premise vor einer Anpassung analysieren
Welche Fragen zu Versionen, Berechtigungen, Integrationen und Releases Sie vor der Schätzung einer Portalanpassung klären sollten.
Die Schätzung einer Anpassung sollte mit dem Nutzerablauf und seinen Abhängigkeiten beginnen. Eine kleine Schaltfläche kann Berechtigungen ändern, Automatisierungen starten oder Daten an ein externes System senden. Eine Bestandsanalyse hilft, den Umfang abzugrenzen, bevor das Team Termine vereinbart.
Hier beschreibe ich mein empfohlenes Vorgehen für den technischen Einstieg in ein Projekt. Es richtet sich vor allem an Bitrix24 On-Premise und ersetzt kein eigenständiges Sicherheits- oder Performance-Audit.
1. Die Nutzeraktion beschreiben
„Die Aufgaben müssen angepasst werden“ beschreibt noch kein Ergebnis. Formulieren Sie einen konkreten Ablauf: Wer öffnet welchen Bereich, trifft welche Auswahl und führt welche Aktion aus? Was soll diese Person danach sehen?
Ein Beispiel: Ein Mitarbeiter sendet eine Anfrage. Die zuständige Person erhält eine Aufgabe, und der Mitarbeiter sieht deren Status. Klären Sie vor der Schätzung, wer die zuständige Person festlegt, was bei erneutem Absenden geschieht und ob jemand fremde Anfragen öffnen kann. Dies ist ein Beispiel und keine Beschreibung einer konkreten Einführung.
Formulieren Sie das Abnahmekriterium aus Nutzersicht. Prüfen Sie anschließend, ob eine Standardfunktion oder vorhandene Integration bereits Teile des Ablaufs abdeckt.
2. Die technische Umgebung erfassen
| Zu klären | Zweck |
|---|---|
| On-Premise oder Cloud, Produktedition | Verfügbare Anpassungswege bestimmen |
| PHP- und betroffene Modulversionen | Code mit der tatsächlichen API abgleichen |
| Lokale Module und Drittanbieter-Module | Verantwortliche der Anwendungslogik finden |
| Hintergrundaufgaben und Bitrix-Agents | Zeitpunkt verzögerter Verarbeitung verstehen |
| Cache und externe Dienste | Zusätzliche Abhängigkeiten erkennen |
| Testumgebung und Release-Verfahren | Sicheren Prüfweg wählen |
Für die erste Analyse brauchen Sie nur die Informationen, die die Aufgabe betreffen. Ein vollständiger Datenbank-Dump oder uneingeschränkter Zugriff darf keine Voraussetzung für ein Gespräch sein. Legen Sie zuerst fest, welche Bereiche gelesen werden dürfen, und vereinbaren Sie anonymisierte Beispiele.
3. Den Datenweg verfolgen
Verfolgen Sie die Aktion von der Oberfläche bis zum Ergebnis: Komponente oder Controller, Berechtigungsprüfung, Anwendungslogik, Speicherung, Ereignis, Hintergrundaufgabe und externer Aufruf. Nicht jedes Projekt enthält alle Schritte, aber eine übersehene Abhängigkeit kann die Schätzung verändern.
Halten Sie für jede Entität die Datenverantwortung fest. Wenn der Katalog aus 1C stammt und ein Nutzer auf der Website einen Wert ändert, muss vorher klar sein, ob diese Änderung den nächsten Austausch übersteht. Ebenso wichtig ist die Unterscheidung zwischen Datenquelle und zwischengespeicherter Kopie.
4. Mehr als den Erfolgsfall prüfen
Prüfen Sie mindestens auch diese Fälle:
- Nutzer ohne erforderliche Rechte können die Aktion auch durch eine direkte HTTP-Anfrage nicht ausführen.
- Erneutes Absenden erzeugt kein unerwünschtes Duplikat.
- Ein Fehler des externen Systems erscheint nicht als erfolgreicher Abschluss.
- Für teilweise ausgeführte Vorgänge gibt es einen verständlichen Wiederherstellungsweg.
- Die Änderung beschädigt keinen bestehenden Ablauf mit denselben Daten.
Passen Sie den Prüfumfang an das Risiko an. Eine neue Schaltflächenfarbe und ein Datenaustausch, der in zwei Systemen Datensätze erzeugt, brauchen unterschiedlich tiefe Prüfungen.
5. Release und Rückkehr zur vorherigen Version vereinbaren
Klären Sie vor der Umsetzung, wer die Änderung veröffentlicht und wo die vorherige Version liegt. Wenn sich Daten ändern, reicht es möglicherweise nicht aus, alte Dateien wiederherzustellen. Prüfen Sie gesondert, ob der alte Code mit der neuen Datenstruktur arbeiten kann.
Nach dem Release ist eine kurze Prüfung erforderlich, die zur ursprünglichen Aufgabe passt. „Die Seite öffnet sich“ ist weniger aussagekräftig als „Ein Nutzer mit den passenden Rechten hat den Ablauf ausgeführt und das erwartete Ergebnis erhalten“.
Was nach der Analyse vorliegen sollte
Die Analyse liefert eine kurze Übersicht: Ziel der Änderung, betroffene Komponenten, Abhängigkeiten, offene Fragen, Etappen, Abnahmekriterien und Release-Bedingungen. Zeigen Sie in der Schätzung, welcher Teil bereits verstanden ist und welche offenen Fragen den Aufwand noch verändern können.
Wenn nur eine API oder ein Hintergrundprozess unklar ist, prüfen Sie zunächst diesen Bereich. Präzisieren Sie danach den Plan. So kann der Auftraggeber entscheiden, und der Entwickler kennt den überprüfbaren Umfang seiner Aufgabe.