Transportsystem - Wie läuft es bei euch?
15 Beiträge
•
Seite 1 von 1
15 Beiträge
Seite 1 von 1
An alle Entwickler...
ich hoffe, ich bin im richtigen Forum mit meiner Frage.
Mich würde mal interessieren, wie in euren Firmen der Lebenszyklus eines ABAP-Programms vom Anlegen bis zum Produktivgang ist. Ich selbst kenne nur unser System. Ich bin bei einer großen Versicherung.
Das läuft folgendermaßen ab...
Es existieren 3 SAP-Umgebungen (Entwicklungssystem, Testsystem(Abnahme) und Produktion). Ein Programm wird im Entwicklungssystem programmiert und anschließend ins Abnahmesystem transportiert. Ggf. transportiert der Entwickler mehrmals nach Abnahme bevor das Programm zum Testen freigegeben wird. Bei uns ist es so, dass im Entwicklungssystem oft keine richtigen Testdaten vorhanden sind und wir Entwickler daher im Abnahmesystem testen müssen. Sind wir Entwickler der Meinung, dass das Programm in Ordnung ist, sagen wir den Testern bescheid. Diese testen dann und haben evtl. noch Fehler entdeckt, die wiederum mit Korrekturen und anschließenden Transporten korrigiert werden. Ist das programm erfolgreich getestet, erteilen die Tester die Freigabe. Draufhin sammelt der Entwickler alle Transporte zusammen, die mit dem Programm in Verbindung stehen und beauftragt das Team der Produktionsfreigabe, dass sie die Transporte in der korrekten Reihenfolge freigeben.
Hier existieren jedoch einige Fehlerquellen:
- Überholung von Transporten, falls bspw. ein anderer Entwickler an einem Funktionsbaustein etwas ändert, den ich auch am Wickel hatte. Angenommen er hat seine Änderung am FuBa vor meiner Änderung gemacht, ich gebe meine Änderung jedoch zuerst nach Produktion, so würde seine Produktionsfreigabe meine Änderungen überschreiben und mein Programm läuft nicht mehr korrekt.
- Vergessen eines Transports bei Produktionsfreigabe
Beim Zusammensuchen der einzelnen Transporte vergesse evtl. einen und lasse die gefundenen nach Produktion transportieren. Programm wird also nicht Produktion korrekt laufen, da evtl. der vergessene Transport eine Änderung an einer Tabelle oder einem FuBa beinhaltet. Konsequenz ist, dass ich mir den Fehler suchen muss und die entsprechnden Objekte nochmals transportieren muss.
Wie läuft das alles bei euch ab? Ähnlich? Genauso? Ganz anders?
Benutzt jemand den SAP Solution Manager? Bringt der hier etwas?
Gruß Andy
ich hoffe, ich bin im richtigen Forum mit meiner Frage.
Mich würde mal interessieren, wie in euren Firmen der Lebenszyklus eines ABAP-Programms vom Anlegen bis zum Produktivgang ist. Ich selbst kenne nur unser System. Ich bin bei einer großen Versicherung.
Das läuft folgendermaßen ab...
Es existieren 3 SAP-Umgebungen (Entwicklungssystem, Testsystem(Abnahme) und Produktion). Ein Programm wird im Entwicklungssystem programmiert und anschließend ins Abnahmesystem transportiert. Ggf. transportiert der Entwickler mehrmals nach Abnahme bevor das Programm zum Testen freigegeben wird. Bei uns ist es so, dass im Entwicklungssystem oft keine richtigen Testdaten vorhanden sind und wir Entwickler daher im Abnahmesystem testen müssen. Sind wir Entwickler der Meinung, dass das Programm in Ordnung ist, sagen wir den Testern bescheid. Diese testen dann und haben evtl. noch Fehler entdeckt, die wiederum mit Korrekturen und anschließenden Transporten korrigiert werden. Ist das programm erfolgreich getestet, erteilen die Tester die Freigabe. Draufhin sammelt der Entwickler alle Transporte zusammen, die mit dem Programm in Verbindung stehen und beauftragt das Team der Produktionsfreigabe, dass sie die Transporte in der korrekten Reihenfolge freigeben.
Hier existieren jedoch einige Fehlerquellen:
- Überholung von Transporten, falls bspw. ein anderer Entwickler an einem Funktionsbaustein etwas ändert, den ich auch am Wickel hatte. Angenommen er hat seine Änderung am FuBa vor meiner Änderung gemacht, ich gebe meine Änderung jedoch zuerst nach Produktion, so würde seine Produktionsfreigabe meine Änderungen überschreiben und mein Programm läuft nicht mehr korrekt.
- Vergessen eines Transports bei Produktionsfreigabe
Beim Zusammensuchen der einzelnen Transporte vergesse evtl. einen und lasse die gefundenen nach Produktion transportieren. Programm wird also nicht Produktion korrekt laufen, da evtl. der vergessene Transport eine Änderung an einer Tabelle oder einem FuBa beinhaltet. Konsequenz ist, dass ich mir den Fehler suchen muss und die entsprechnden Objekte nochmals transportieren muss.
Wie läuft das alles bei euch ab? Ähnlich? Genauso? Ganz anders?
Benutzt jemand den SAP Solution Manager? Bringt der hier etwas?
Gruß Andy
Zuletzt geändert von airwaver am 13.08.2012 06:35, insgesamt 1-mal geändert.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Hi Andy,
das kenne ich genau so...!
Es gibt von Realtech ein Tool, mitdem man dem Chaos entgegenwirken kann (http://www.realtech.com/wInternational/ ... erview.php).
Ich kenne den nicht im Detail, weiss aber, dass ein Überholen von Transporten ausgeschlossen wird, weil das Tool erkennt, welche Transporte vorher noch ins system müssen.
Zudem kann man da noch Änderungen dokumentieren, was wohl für Pharma-Firmen wichtig und interessant ist.
Ich habe mal ein Programm geschrieben, was zumindest für Programme eine Übersicht über den "Transportstatus" ausgibt: http://www.tricktresor.de/content/index ... 27&aID=358
Alles andere als Kontrolle ist Murks ("Modulverantwortliche, "Freigabe- und Transportgenehmigungen auf Antrag durch die Basis etc"). Letztendlich weiss nur der Programmierer, welche Objekte und Aufträge zusammengehören. Und wenn zwischendurch jemand anderes einen Funktionsbaustein/ eine Struktur oder Ähnliches ändert und transportiert, dann knallts halt.
Es ist mir auch unverständlich, warum solche Tools (wahrscheinlich gibt es noch andere, nicht nur von Realtech) nicht viel verbreiteter sind. Denn irgendwann knallts immer. Meistens dann, wenn man es gar nicht gebrauchen kann
und dann werden besagte Kontrollmechanismen aus dem Boden gestampft, die allen das Leben schwer machen und letztendlich nur bis zum nächsten Knall halten.
soviel von mir...
das kenne ich genau so...!
Es gibt von Realtech ein Tool, mitdem man dem Chaos entgegenwirken kann (http://www.realtech.com/wInternational/ ... erview.php).
Ich kenne den nicht im Detail, weiss aber, dass ein Überholen von Transporten ausgeschlossen wird, weil das Tool erkennt, welche Transporte vorher noch ins system müssen.
Zudem kann man da noch Änderungen dokumentieren, was wohl für Pharma-Firmen wichtig und interessant ist.
Ich habe mal ein Programm geschrieben, was zumindest für Programme eine Übersicht über den "Transportstatus" ausgibt: http://www.tricktresor.de/content/index ... 27&aID=358
Alles andere als Kontrolle ist Murks ("Modulverantwortliche, "Freigabe- und Transportgenehmigungen auf Antrag durch die Basis etc"). Letztendlich weiss nur der Programmierer, welche Objekte und Aufträge zusammengehören. Und wenn zwischendurch jemand anderes einen Funktionsbaustein/ eine Struktur oder Ähnliches ändert und transportiert, dann knallts halt.
Es ist mir auch unverständlich, warum solche Tools (wahrscheinlich gibt es noch andere, nicht nur von Realtech) nicht viel verbreiteter sind. Denn irgendwann knallts immer. Meistens dann, wenn man es gar nicht gebrauchen kann
und dann werden besagte Kontrollmechanismen aus dem Boden gestampft, die allen das Leben schwer machen und letztendlich nur bis zum nächsten Knall halten.soviel von mir...
Hallo,
das kenne ich genau so...!
Bei Aufwendigeren Dingen reduziere das Problem, indem ich den Orginalauftrag offen lasse und immer nur Kopien des Transportauftrages ins Testsystem transportiere. Dadurch habe ich nur einen Auftrag der alle Änderungen beinhaltet. Und 3. können nicht unbemerkt Änderungen an meinen Objekten vornehmen.
- Überholung von Transporten, falls bspw. ein anderer Entwickler an einem Funktionsbaustein etwas ändert, den ich auch am Wickel hatte. --> dagegen hilft nur ein Remotevergleich mit den Produktivsystem und telefonieren.
Bei komlexen Entwicklungen fasse ich sämtliche Transportaufträge zu einer Kopie von Transportaufträgen zusammen (Workbench&Customizing) und nur dieser wird Transportiert, woduch selbst produzierte Überholer ausgeschlossen sind.
Und bei Produktivsetzungen, die den Geschäftsbetrieb erheblich gefährden erfolgt eine Testproduktivsetzung inkl. Test des Transports der Transporte in eine frische Spiegelung des Produktivsystems.
Gruß Alex
das kenne ich genau so...!
Bei Aufwendigeren Dingen reduziere das Problem, indem ich den Orginalauftrag offen lasse und immer nur Kopien des Transportauftrages ins Testsystem transportiere. Dadurch habe ich nur einen Auftrag der alle Änderungen beinhaltet. Und 3. können nicht unbemerkt Änderungen an meinen Objekten vornehmen.
- Überholung von Transporten, falls bspw. ein anderer Entwickler an einem Funktionsbaustein etwas ändert, den ich auch am Wickel hatte. --> dagegen hilft nur ein Remotevergleich mit den Produktivsystem und telefonieren.
Bei komlexen Entwicklungen fasse ich sämtliche Transportaufträge zu einer Kopie von Transportaufträgen zusammen (Workbench&Customizing) und nur dieser wird Transportiert, woduch selbst produzierte Überholer ausgeschlossen sind.
Und bei Produktivsetzungen, die den Geschäftsbetrieb erheblich gefährden erfolgt eine Testproduktivsetzung inkl. Test des Transports der Transporte in eine frische Spiegelung des Produktivsystems.
Gruß Alex
Hallo,
bei unserer SAP Umgebung läuft das theoretisch auch so ab wie beschrieben.
Ich hab aber noch ein paar Anmerkungen die sich so im Laufe der Zeit angesammelt haben.
Es wird immer kompliziert wenn eine gemeinsame "Basis", also Funktionen die von mehreren Programmen benutzt werden, existiert. Hier sind immer die Entwickler in der Verantwortung. Falls man Änderungen an der "Basis" machen muß muß man eben alle anderen Programme die diese nutzen testen und falls Nacharbeiten notwendig sind mittransportieren. Das ist halt der Fluch des zentralen Dictionarys innerhalb von SAP bzw. dieser "Basis". Das Problem denk ich kann man nur organisatorisch lösen (denke mal Tools helfen nur die Organisation zu unterstützen). Oder aber man entscheidet sich dagegen Funktionen allgemein verfügbar zu machen bzw Funktionen anderer Programmierer direkt zu nutzen (Objekt kopieren und das eigene nutzen). So hat man das Problem der "Basis" auch gelöst, ist aber etwas unsauber.
Das Problem das man einen Auftrag vergisst kann man mit Disziplin oder Hilfsprogrämmchen lösen. Es muß einfach für eine Änderung eines Programms immer der vorherige Transport in den aktuellen Transport mitaufgenommen werden. Dadurch erreicht man das immer alle Objekte die zum Programm gehören in dem Transport enthalten sind. Man kann sich theoretisch ein Tool schreiben das nach der Transportfreigabe einen neuen Transport mit den Objekten des alten Transports erzeugt und z.B. im Namen eine Nummer hochzählt. So kann man keine Objekte vergessen.
Gruß,
Flo
bei unserer SAP Umgebung läuft das theoretisch auch so ab wie beschrieben.
Ich hab aber noch ein paar Anmerkungen die sich so im Laufe der Zeit angesammelt haben.
Es wird immer kompliziert wenn eine gemeinsame "Basis", also Funktionen die von mehreren Programmen benutzt werden, existiert. Hier sind immer die Entwickler in der Verantwortung. Falls man Änderungen an der "Basis" machen muß muß man eben alle anderen Programme die diese nutzen testen und falls Nacharbeiten notwendig sind mittransportieren. Das ist halt der Fluch des zentralen Dictionarys innerhalb von SAP bzw. dieser "Basis". Das Problem denk ich kann man nur organisatorisch lösen (denke mal Tools helfen nur die Organisation zu unterstützen). Oder aber man entscheidet sich dagegen Funktionen allgemein verfügbar zu machen bzw Funktionen anderer Programmierer direkt zu nutzen (Objekt kopieren und das eigene nutzen). So hat man das Problem der "Basis" auch gelöst, ist aber etwas unsauber.
Das Problem das man einen Auftrag vergisst kann man mit Disziplin oder Hilfsprogrämmchen lösen. Es muß einfach für eine Änderung eines Programms immer der vorherige Transport in den aktuellen Transport mitaufgenommen werden. Dadurch erreicht man das immer alle Objekte die zum Programm gehören in dem Transport enthalten sind. Man kann sich theoretisch ein Tool schreiben das nach der Transportfreigabe einen neuen Transport mit den Objekten des alten Transports erzeugt und z.B. im Namen eine Nummer hochzählt. So kann man keine Objekte vergessen.
Gruß,
Flo
Danke für die Antworten... Da gehts den anderen Entwicklern also genauso wie uns. Im Grunde hilft für eine Optimierung des Transportwesens nur eine gute Organisation und Kommunikation.
Ich hatte letzte Woche einen Hinweis für den ALV-Druck eingespielt. Der Hinweis hat eine Sache korrigiert und gleich eine andere (und zwar viiiel wichtigere) kaputt gemacht. Auf einmal wurden die Druckeigenschaften nicht mehr übernommen. Ich hatte aber nicht mit den anderen Entwicklern abgesprichen, dass ich am ALV was ändere. Somit haben die Kollegen das Problem entdeckt und den Fehler gesucht. Ich habe irgendwann mitgesucht, weil ich auch darauf gestoßen bin. Ich hatte aber total vergessen, dass ich einen Hinweis eingespielt hatte. Somit haben 4 Mann 2 Tage lang nach dem Fehler und einer Lösung gesucht und irgendwann ist einem aufgefallen, dass ich eben diesen Hinweis eingespielt habe und ab dann erst der Fehler auftrat.
Im Hinweis wurde sogar schon auf einen Folgehinweis mit Korrektur verwiesen. Oh man, und sowas passiert mir! Naja, jetzt läuft wieder alles.
Aber hätte ich mal mit den Kollegen vorher besprochen, dass ich den Hinweis einbaue, hätten alle bescheid gewusst und es wäre viel schneller eine Lösung gefunden worden.
Zu euren Antworten:
@ewx:
Dein Programm habe ich nicht richtig verstanden. Weiß nicht genau, was es macht und wozu ich es gebrauchen könnte. Wohin wird verzweigt, wenn ich einen Doppelklick in der Liste mache?
@A6272:
Auftrag kopieren? Du nimmst also deinen letzten Auftrag zu dem Programm und kopierst den erstmal. Dann gehts erst ans Ändern? So blockiere ich quasi alle Objekte, die ich wegen diesem Programm mal angefasst habe. Aber nach 10 Transporten möchte ich Objekt A nicht mehr anfassen. Also muss ich es aus dem Transport löschen. Und irgendwann habe ich 20 Objekte, die ich nciht mehr anfassen möchte, usw.... Ist meiner Meinung nach eine akzeptable Lösung. Werde ich wohl auch ab und zu mal einsetzen, wenn ich an Programmen dran bin, bei denen ich absolut nicht will, dass jemand etwas an dort genutzten globalen Objekten ändert.
@Flo:
Globale Funktionen sollten schon global bleiben. Die meisten Änderungen können ja auch für andere Module nützlich oder notwendig sein.
Wie wäre es mit einem Tool, in das ich Eintrage, wenn ich etwas an einem SAP-Standardobjekt ändere? Besser noch, wenn ich etwas an einem SAP-Standardobjekt ändere, das nicht meinen Modulen zugeordnet ist. Wenn ich im Modul FS arbeite, sollte also etwas ins Tool eingetragen werden, wenn ich etwas am ALV ändere (der gehört zu BC). Was meint ihr dazu?
Gruß
Andy
Ich hatte letzte Woche einen Hinweis für den ALV-Druck eingespielt. Der Hinweis hat eine Sache korrigiert und gleich eine andere (und zwar viiiel wichtigere) kaputt gemacht. Auf einmal wurden die Druckeigenschaften nicht mehr übernommen. Ich hatte aber nicht mit den anderen Entwicklern abgesprichen, dass ich am ALV was ändere. Somit haben die Kollegen das Problem entdeckt und den Fehler gesucht. Ich habe irgendwann mitgesucht, weil ich auch darauf gestoßen bin. Ich hatte aber total vergessen, dass ich einen Hinweis eingespielt hatte. Somit haben 4 Mann 2 Tage lang nach dem Fehler und einer Lösung gesucht und irgendwann ist einem aufgefallen, dass ich eben diesen Hinweis eingespielt habe und ab dann erst der Fehler auftrat.
Im Hinweis wurde sogar schon auf einen Folgehinweis mit Korrektur verwiesen. Oh man, und sowas passiert mir! Naja, jetzt läuft wieder alles.Aber hätte ich mal mit den Kollegen vorher besprochen, dass ich den Hinweis einbaue, hätten alle bescheid gewusst und es wäre viel schneller eine Lösung gefunden worden.
Zu euren Antworten:
@ewx:
Dein Programm habe ich nicht richtig verstanden. Weiß nicht genau, was es macht und wozu ich es gebrauchen könnte. Wohin wird verzweigt, wenn ich einen Doppelklick in der Liste mache?
@A6272:
Auftrag kopieren? Du nimmst also deinen letzten Auftrag zu dem Programm und kopierst den erstmal. Dann gehts erst ans Ändern? So blockiere ich quasi alle Objekte, die ich wegen diesem Programm mal angefasst habe. Aber nach 10 Transporten möchte ich Objekt A nicht mehr anfassen. Also muss ich es aus dem Transport löschen. Und irgendwann habe ich 20 Objekte, die ich nciht mehr anfassen möchte, usw.... Ist meiner Meinung nach eine akzeptable Lösung. Werde ich wohl auch ab und zu mal einsetzen, wenn ich an Programmen dran bin, bei denen ich absolut nicht will, dass jemand etwas an dort genutzten globalen Objekten ändert.
@Flo:
Globale Funktionen sollten schon global bleiben. Die meisten Änderungen können ja auch für andere Module nützlich oder notwendig sein.
Wie wäre es mit einem Tool, in das ich Eintrage, wenn ich etwas an einem SAP-Standardobjekt ändere? Besser noch, wenn ich etwas an einem SAP-Standardobjekt ändere, das nicht meinen Modulen zugeordnet ist. Wenn ich im Modul FS arbeite, sollte also etwas ins Tool eingetragen werden, wenn ich etwas am ALV ändere (der gehört zu BC). Was meint ihr dazu?
Gruß
Andy
Hallo,
so war das nicht gemeint. Der Orginalauftrag bleibt offen und nur Kopien dieses Auftrags kommen ins Testsystem. Wenn alles OK ist, dann wird der Orginalauftrag freigegeben und in die Produktion transportiert. Nur wärend der Entwicklungs und Testzeit sind alle geänderten Objekte gesperrt.
Kommt nach Produktivsetzung eine Änderung, so wird nur das zu ändernde Objekt gesperrt.
Eine Kopie eines Transportauftrages setzt keine Sperre auf irgendein Objekt!
Gruß Alex
so war das nicht gemeint. Der Orginalauftrag bleibt offen und nur Kopien dieses Auftrags kommen ins Testsystem. Wenn alles OK ist, dann wird der Orginalauftrag freigegeben und in die Produktion transportiert. Nur wärend der Entwicklungs und Testzeit sind alle geänderten Objekte gesperrt.
Kommt nach Produktivsetzung eine Änderung, so wird nur das zu ändernde Objekt gesperrt.
Eine Kopie eines Transportauftrages setzt keine Sperre auf irgendein Objekt!
Gruß Alex
Hallo Zusammen,
die Systemlandschaft ist bei uns ähnlich, ebenso die Probleme die auftauchen können.
Was das "Zusammenhalten" von Transportobjekten angeht, habe ich bei uns ein Programm gebaut, was den Transport freigibt, ihn aber im Hintergrund sofort wieder kopiert und die Objekte sperrt (wichtig!).
So kann man in Ruhe mehrere Schleifen über die Testumgebung ziehen, bis die Freigabe für die Produktion erfolgt.
Problematisch wird es, wenn ein anderer Entwickler an ein gesperrtes Objekt muss. Dann ist wieder Disziplin und Koordination gefragt, anders geht es nicht.
Er muss dann seinen schon bestehenden Transport an den anderen anhängen und es muss irgendwann gemeinsam in die Produktion transportiert werden oder sehr sorgfältig die Aufträge zerlegt werden.
Was "plötzlich" auftretende Fehler in der Produktion angeht, lautet immer zu erst die Frage: "Wer hat was wann transportiert?"
Auch wenn der Transport auf den ersten Blick nicht unbedingt was damit zu tun hatte, kann es ja die tollsten Seiteneffekte geben.
Gruß
ST22
die Systemlandschaft ist bei uns ähnlich, ebenso die Probleme die auftauchen können.
Was das "Zusammenhalten" von Transportobjekten angeht, habe ich bei uns ein Programm gebaut, was den Transport freigibt, ihn aber im Hintergrund sofort wieder kopiert und die Objekte sperrt (wichtig!).
So kann man in Ruhe mehrere Schleifen über die Testumgebung ziehen, bis die Freigabe für die Produktion erfolgt.
Problematisch wird es, wenn ein anderer Entwickler an ein gesperrtes Objekt muss. Dann ist wieder Disziplin und Koordination gefragt, anders geht es nicht.
Er muss dann seinen schon bestehenden Transport an den anderen anhängen und es muss irgendwann gemeinsam in die Produktion transportiert werden oder sehr sorgfältig die Aufträge zerlegt werden.
Was "plötzlich" auftretende Fehler in der Produktion angeht, lautet immer zu erst die Frage: "Wer hat was wann transportiert?"
Auch wenn der Transport auf den ersten Blick nicht unbedingt was damit zu tun hatte, kann es ja die tollsten Seiteneffekte geben.
Gruß
ST22
Nochmals danke für die Antworten.
@A6272: Ich hatte es wohl vorher nicht richtig verstanden. Aber die des Einspielens einer Kopie des Transportes ins Testsystem finde ich verdammt gut. Das werde ich hier auch mal anbringen.
@ST22: Dein Programm hört sich auch echt gut an. Müsstest du mal bei Tricktresor vorstellen oder an ähnlichen Stellen.
Mich würde aber noch interssieren, bei welchen Unternehmen ihr beschäftigt seid. Wenn ihr keine Namen nenn wollt, ist es schon ok; aber vielleicht verratet ihr ja die Branche und Größe.
Gruß
Andy
@A6272: Ich hatte es wohl vorher nicht richtig verstanden. Aber die des Einspielens einer Kopie des Transportes ins Testsystem finde ich verdammt gut. Das werde ich hier auch mal anbringen.
@ST22: Dein Programm hört sich auch echt gut an. Müsstest du mal bei Tricktresor vorstellen oder an ähnlichen Stellen.
Mich würde aber noch interssieren, bei welchen Unternehmen ihr beschäftigt seid. Wenn ihr keine Namen nenn wollt, ist es schon ok; aber vielleicht verratet ihr ja die Branche und Größe.
Gruß
Andy
Beitrag
von abap-expert (ForumUser / 7 / 0 /
1
)
»
Hallo Zusammen,
nur der Vollständigkeit halber möchte ich erwähnen, dass trotz aller organisatorischer Massnahmen, Fehler auftreten können. Mit selbst geschriebenen Tools kann man sich natürlich behelfen. Für die Erstellung eines sichern und generischen Werkzeugs fehlt allerdings oft die Zeit neben dem eigentlichen Aufgaben des Arbeitstags. Zudem müssen diese regelmäßig gewartet werden und z.B. mit einem Support Pack der SAP angepasst werden. Neben kontinuierlichen Pflegeaufwand dieser Tools ist das Risiko des Verlusts von Knowhow (z.B. Mitarbeiterwechsel) nicht zu vernachlässigen. Dann muss sich ein anderer Mitarbeit in die Lösung einarbeiten und die Pflege übernehmen. Daher empfiehlt es sich ein standardisierte Lösung einzuführen, welche einfach und effektiv mit wenig Schulungsaufwand zu bedienen ist.
Um das Transportwesen sicherer zu gestalten haben wir eine Lösung entwickelt,..
..die eine Überholer-Situation im Workbench wie auch im Customizing Bereich verhindert.
..kritische oder global verwendete Objekte erkennt und darauf aufmerksam macht.
..einen einfachen Genehmigungsworkflow beeinhaltet.
..die Möglichkeit Transport-Reihenfolgen zu definieren und damit sog. Cut-Over Listen zu erstellen und diese für einen Go-Live zu verwenden.
..Abhängigkeiten zwischen Transporten zu bilden, z.B. Vorgänger und Nachfolger sowie fachl. Abhängigkeiten.
..innerhalb von 2 Tagen installiert und konfiguriert ist.
usw.
Beste Grüße,
Christoph
nur der Vollständigkeit halber möchte ich erwähnen, dass trotz aller organisatorischer Massnahmen, Fehler auftreten können. Mit selbst geschriebenen Tools kann man sich natürlich behelfen. Für die Erstellung eines sichern und generischen Werkzeugs fehlt allerdings oft die Zeit neben dem eigentlichen Aufgaben des Arbeitstags. Zudem müssen diese regelmäßig gewartet werden und z.B. mit einem Support Pack der SAP angepasst werden. Neben kontinuierlichen Pflegeaufwand dieser Tools ist das Risiko des Verlusts von Knowhow (z.B. Mitarbeiterwechsel) nicht zu vernachlässigen. Dann muss sich ein anderer Mitarbeit in die Lösung einarbeiten und die Pflege übernehmen. Daher empfiehlt es sich ein standardisierte Lösung einzuführen, welche einfach und effektiv mit wenig Schulungsaufwand zu bedienen ist.
Um das Transportwesen sicherer zu gestalten haben wir eine Lösung entwickelt,..
..die eine Überholer-Situation im Workbench wie auch im Customizing Bereich verhindert.
..kritische oder global verwendete Objekte erkennt und darauf aufmerksam macht.
..einen einfachen Genehmigungsworkflow beeinhaltet.
..die Möglichkeit Transport-Reihenfolgen zu definieren und damit sog. Cut-Over Listen zu erstellen und diese für einen Go-Live zu verwenden.
..Abhängigkeiten zwischen Transporten zu bilden, z.B. Vorgänger und Nachfolger sowie fachl. Abhängigkeiten.
..innerhalb von 2 Tagen installiert und konfiguriert ist.
usw.
Beste Grüße,
Christoph
visit: http://www.abap-experts.com
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Zu, de Thread habe ich doch glatt übersehen - dabei ist das eigentlich mein Spezialthema, weil mich inzwischen mehrere Kunden auf die hier genannten Probleme angesprochen habe.
Zunächst:
Ich habe eine ganze Reihe von Kunden, bei denen die Situation sehr unterschiedlich ist:
1. We are in the 80s, dude!
Ein Kunde machte das genau so wie du beschrieben hast, bis ich in einem Vortrag dargelegt habe, wie rückständig das ist. Das wollte der Kunde so nicht hören, gesagt habe ich es ihm trotzdem in diesen Worten. Wir hatten zum Teil hunderte Transportaufträge in einer Produktivsetzung, die Fehlerhäufigkeit ist enorm.
Du weißt ja schon, dass eine Auftragsfreigabe die Sperre aufhebt, also kann sich ein anderer Entwickler das Objekt schnappen (zum Beispiel zur Fehlerkorrektur) und an dir vorbeitransportieren und BUMM.
Sammelaufträge sind Mist, weil die die aktuelle Version jedes Objektes in den Auftrag schreiben, das ist aber oft nicht erwünscht (weil zum Beispiel schon ein anderes Projekt an dem Ding dran ist oder eine Reparatur.
Wer so transportiert, hat zuviel Zeit und zuviel Geld.
2. Vertrauen Sie mir, ich weiß was ich tue
Schon besser ist es, den Auftrag gar nicht freizugeben, sondern bis vor der Produktivsetzung offen zu halten. Wenn DANN jemand an eines deiner Objekte rangeht, wird er benachrichtigt und kann keinen neuen Auftrag mit diesem Objekt erzeugen. Will er an dir vorbeitransportieren, muss er sich mit dir absprechen - eine Fehlerquelle weniger.
Die Frage ist also: Wie kriege ich die Objekte ins Testsystem????
Hier gibt es mehrere Wege: Man kann unmittelbar nach der Freigabe einen neuen Auftrag anlegen und die Objekte des freigegebenen Auftrages darin aufnehmen. Dann muss man nur den letzten produktivsetzen und kann alle anderen in der Queue löschen / ablehnen lassen. Ein Verfahren, das Auditoren GAR nicht mögen. Das ist etwa das, was ST22 automatisiert macht.
Außerdem sollte man daran denken, dass man mit jeder Transportfreigabe eine Version jedes enthaltenen Objektes erzeugt. Wenn du einen Transportauftrag mit 50 Objekten hast, eine Codingzeile änderst und den Auftrag freigibst, hast du von 49 Objekten eine Version angelegt, die identisch zur vorherigen ist. Mach das oft genug und du findest nie mehr was wieder. Das ist die Schwäche beim Konzept von st22.
Da ist es schon klüger, einen Transport von Kopien anzulegen und diesen zu transportieren und den ursprünglichen Auftrag gar nicht freizugeben (im Groben macht das der Solution Manager so). Das macht aber NUR Sinn, wenn man alle nicht geänderten Objekte rauswirft, die nicht geändert wurden, sonst schreibst du wieder identische Versionen.
Außerdem gibt es noch ZPOP - das ist ein Tool mit dem ich bei einem meiner Kunden erfolgreich arbeite (und der Entwickler seit viel mehr Jahren bei mehreren Kunden). Das kopiert Objekte via Filesystem von einer Maschine auf eine andere, ohne dabei Versionen zu schreiben. Quasi am TMS vorbei. Dieses Tool habe ich auch beim obigen Kunden (aus den 80ern) eingesetzt, als wir für ein Projekt eine eigene Maschine bekamen und Riesenbohei um den Anschluss an das Transportwesen gemacht wurde. Ich hab ZPOP installiert, so brauchten wir kein funktionierendes Transportwesen LOL
3. Arbeiten wie die Profis
Ein funktionierendes Transportwesen ist immer auch ein Element des Entwicklungsprozesses (das ist das, was der "80er Jahre Kunde" gar nicht hatte) und ein Glied in der Kette "Ticketaufnahme - Ticketzuweisung - Entwicklung - Test - Produktivsetzung - Dokumentation". (Beim letzten Punkt werden einige sagen:"Wasn das????")
So ist der Solution Manager ein recht gutes Tool, um diesen Prozess inkl. Dokumentation integriert hinzubekommen, es gibt aber auch andere. Insbesondere gibt es Non-SAP-Prozesse, weshalb viele Jira verwenden (finde ich gar nicht schlecht), dann gibt es aber Probleme mit der Integration, man kann Jira und SolMan nicht miteinander vernetzen.
Abgesehen braucht man den SolMan eh für den SAP Support....
Bei meinem aktuellen Kunden fühle ich mich wie im Paradies: Auf dem Entwicklungssystem ein Mandant mit guten Testdaten, kein Transport geht ohne bestandenen (und schriftlich dokumentierten!) Unit Test in das Testsystem. So hat man in der Regel ohnehin nur einen Auftrag. Nur wenn beim User Acceptance Test noch Bedarfe entstehen, gibt es einen weiteren. So viel Übersicht hatte ich noch NIE - bei keinem Kunden. Ich hoffe, ich darf hier noch lange arbeiten. Leider hat man sich beim Dokumentieren auf die überholten Werkzeuge Word+Excel+Filesystem verlassen, wo ich ein Wiki viel besser gefunden hätte.
Soviel von mir zu dem Thema...
Zunächst:
Das ist nicht nur wichtig und interessant, die MÜSSEN das dokumentieren, schon aus Audit-Gründen. Daran hängt unter anderem nicht weniger als die Existenz des Unternehmens.ewx hat geschrieben: Zudem kann man da noch Änderungen dokumentieren, was wohl für Pharma-Firmen wichtig und interessant ist.
Im Grunde genommen beschreibst du einen Umgang mit dem Transportwesen aus den 80er Jahren (was unter Nennung des Unternehmensnamens nicht witzig ist), was ein deutliches Zeichen von Rückständigkeit und Unverständnis in der Thematik ausdrückt.airwaver hat geschrieben:Mich würde mal interessieren, wie in euren Firmen der Lebenszyklus eines ABAP-Programms vom Anlegen bis zum Produktivgang ist.
Ich habe eine ganze Reihe von Kunden, bei denen die Situation sehr unterschiedlich ist:
1. We are in the 80s, dude!
Ein Kunde machte das genau so wie du beschrieben hast, bis ich in einem Vortrag dargelegt habe, wie rückständig das ist. Das wollte der Kunde so nicht hören, gesagt habe ich es ihm trotzdem in diesen Worten. Wir hatten zum Teil hunderte Transportaufträge in einer Produktivsetzung, die Fehlerhäufigkeit ist enorm.
Du weißt ja schon, dass eine Auftragsfreigabe die Sperre aufhebt, also kann sich ein anderer Entwickler das Objekt schnappen (zum Beispiel zur Fehlerkorrektur) und an dir vorbeitransportieren und BUMM.
Sammelaufträge sind Mist, weil die die aktuelle Version jedes Objektes in den Auftrag schreiben, das ist aber oft nicht erwünscht (weil zum Beispiel schon ein anderes Projekt an dem Ding dran ist oder eine Reparatur.
Wer so transportiert, hat zuviel Zeit und zuviel Geld.
2. Vertrauen Sie mir, ich weiß was ich tue
Schon besser ist es, den Auftrag gar nicht freizugeben, sondern bis vor der Produktivsetzung offen zu halten. Wenn DANN jemand an eines deiner Objekte rangeht, wird er benachrichtigt und kann keinen neuen Auftrag mit diesem Objekt erzeugen. Will er an dir vorbeitransportieren, muss er sich mit dir absprechen - eine Fehlerquelle weniger.
Die Frage ist also: Wie kriege ich die Objekte ins Testsystem????
Hier gibt es mehrere Wege: Man kann unmittelbar nach der Freigabe einen neuen Auftrag anlegen und die Objekte des freigegebenen Auftrages darin aufnehmen. Dann muss man nur den letzten produktivsetzen und kann alle anderen in der Queue löschen / ablehnen lassen. Ein Verfahren, das Auditoren GAR nicht mögen. Das ist etwa das, was ST22 automatisiert macht.
Außerdem sollte man daran denken, dass man mit jeder Transportfreigabe eine Version jedes enthaltenen Objektes erzeugt. Wenn du einen Transportauftrag mit 50 Objekten hast, eine Codingzeile änderst und den Auftrag freigibst, hast du von 49 Objekten eine Version angelegt, die identisch zur vorherigen ist. Mach das oft genug und du findest nie mehr was wieder. Das ist die Schwäche beim Konzept von st22.
Da ist es schon klüger, einen Transport von Kopien anzulegen und diesen zu transportieren und den ursprünglichen Auftrag gar nicht freizugeben (im Groben macht das der Solution Manager so). Das macht aber NUR Sinn, wenn man alle nicht geänderten Objekte rauswirft, die nicht geändert wurden, sonst schreibst du wieder identische Versionen.
Außerdem gibt es noch ZPOP - das ist ein Tool mit dem ich bei einem meiner Kunden erfolgreich arbeite (und der Entwickler seit viel mehr Jahren bei mehreren Kunden). Das kopiert Objekte via Filesystem von einer Maschine auf eine andere, ohne dabei Versionen zu schreiben. Quasi am TMS vorbei. Dieses Tool habe ich auch beim obigen Kunden (aus den 80ern) eingesetzt, als wir für ein Projekt eine eigene Maschine bekamen und Riesenbohei um den Anschluss an das Transportwesen gemacht wurde. Ich hab ZPOP installiert, so brauchten wir kein funktionierendes Transportwesen LOL
3. Arbeiten wie die Profis
Ein funktionierendes Transportwesen ist immer auch ein Element des Entwicklungsprozesses (das ist das, was der "80er Jahre Kunde" gar nicht hatte) und ein Glied in der Kette "Ticketaufnahme - Ticketzuweisung - Entwicklung - Test - Produktivsetzung - Dokumentation". (Beim letzten Punkt werden einige sagen:"Wasn das????")
So ist der Solution Manager ein recht gutes Tool, um diesen Prozess inkl. Dokumentation integriert hinzubekommen, es gibt aber auch andere. Insbesondere gibt es Non-SAP-Prozesse, weshalb viele Jira verwenden (finde ich gar nicht schlecht), dann gibt es aber Probleme mit der Integration, man kann Jira und SolMan nicht miteinander vernetzen.
Abgesehen braucht man den SolMan eh für den SAP Support....
Bei meinem aktuellen Kunden fühle ich mich wie im Paradies: Auf dem Entwicklungssystem ein Mandant mit guten Testdaten, kein Transport geht ohne bestandenen (und schriftlich dokumentierten!) Unit Test in das Testsystem. So hat man in der Regel ohnehin nur einen Auftrag. Nur wenn beim User Acceptance Test noch Bedarfe entstehen, gibt es einen weiteren. So viel Übersicht hatte ich noch NIE - bei keinem Kunden. Ich hoffe, ich darf hier noch lange arbeiten. Leider hat man sich beim Dokumentieren auf die überholten Werkzeuge Word+Excel+Filesystem verlassen, wo ich ein Wiki viel besser gefunden hätte.
Soviel von mir zu dem Thema...
Zuletzt geändert von ralf.wenzel am 15.08.2012 12:54, insgesamt 2-mal geändert.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Ich weiß, dass das viele machen, aber ich möchte dennoch mal darauf hinweisen, dass das kritisch ist, weil man im Testsystem oft andere (mehr!) Berechtigungen hat als im Produktivsystem. Damit sieht man Daten, von denen man im Produktivsystem bewusst ausgeschlossen wurde.A6272 hat geschrieben: Und bei Produktivsetzungen, die den Geschäftsbetrieb erheblich gefährden erfolgt eine Testproduktivsetzung inkl. Test des Transports der Transporte in eine frische Spiegelung des Produktivsystems.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Moin Ralf,
das Thema ist ja schon etwas älter. Seitdem hat sich hier auch einiges getan.
Ich konnte aus deiner Antwort leider nicht herauslesen, was aus deiner Sicht die beste Lösung für Überholer, wenige Versionen, Sperren, etc. ist. Daher verstehe ich auch nicht, was du mit "80s" meinst.
Ich hatte im Juni 2012 den folgenden Threat zu ähnlichem Thema eröffnet: http://www.abapforum.com/forum/viewtopi ... 63&start=0.
Wir haben uns nun für den Realtech TransportManager entschieden. Bin mal gespannt, ob dieser unsere Anforderungen komplett abdeckt. Ein PoC steht bevor. Ich hoffe, dass wir dadurch nicht Schwachstellen verlagern, also dass wir einige Schwachstellen verbesern, uns aber andere aufmachen. Wir werden sehen ...
Gruß Andi
das Thema ist ja schon etwas älter. Seitdem hat sich hier auch einiges getan.
Ich konnte aus deiner Antwort leider nicht herauslesen, was aus deiner Sicht die beste Lösung für Überholer, wenige Versionen, Sperren, etc. ist. Daher verstehe ich auch nicht, was du mit "80s" meinst.
Ich hatte im Juni 2012 den folgenden Threat zu ähnlichem Thema eröffnet: http://www.abapforum.com/forum/viewtopi ... 63&start=0.
Wir haben uns nun für den Realtech TransportManager entschieden. Bin mal gespannt, ob dieser unsere Anforderungen komplett abdeckt. Ein PoC steht bevor. Ich hoffe, dass wir dadurch nicht Schwachstellen verlagern, also dass wir einige Schwachstellen verbesern, uns aber andere aufmachen. Wir werden sehen ...
Gruß Andi
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Das hängt vom Prozess ab, es gibt keine allgemeingültige Lösung für alle Kunden - DAS hatte ich versucht, rüberzubringen.airwaver hat geschrieben:Ich konnte aus deiner Antwort leider nicht herauslesen, was aus deiner Sicht die beste Lösung für Überholer, wenige Versionen, Sperren, etc. ist. Daher verstehe ich auch nicht, was du mit "80s" meinst.
Einen Thread, wie eine Drohung klang das nun wirklich nicht.airwaver hat geschrieben:Ich hatte im Juni 2012 den folgenden Threat zu ähnlichem Thema eröffnet: http://www.abapforum.com/forum/viewtopi ... 63&start=0.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Anmerkung zum Fluch des zentralen Dictionaries:
Hier ist das Konzept von Unix-Library gut mit Versionsnummern A.B.C:
A: wird nur hochgezählt wenn neue Features kommen und die neue Version nicht mehr abwärtskompatibel ist
B: wird nur hochgezählt, wenn neue Features kommen und die neue Version abwärtskompatibel ist
C: wird bei Bugfixes hochgezählt (abwärtskompatibel ohne neue Features)
Die Versionsnr. schreiben wir dann in die Dokumentation zum Transportauftrag
So haben wir beschlossen in Zukunft unsere ABAP-"Libraries" im SAP zu verwalten.
Ändert sich nur B oder C braucht man nicht mehr alle Programme, die diese
"Library" verwendent, zu kontrollieren.
Hier ist das Konzept von Unix-Library gut mit Versionsnummern A.B.C:
A: wird nur hochgezählt wenn neue Features kommen und die neue Version nicht mehr abwärtskompatibel ist
B: wird nur hochgezählt, wenn neue Features kommen und die neue Version abwärtskompatibel ist
C: wird bei Bugfixes hochgezählt (abwärtskompatibel ohne neue Features)
Die Versionsnr. schreiben wir dann in die Dokumentation zum Transportauftrag
So haben wir beschlossen in Zukunft unsere ABAP-"Libraries" im SAP zu verwalten.
Ändert sich nur B oder C braucht man nicht mehr alle Programme, die diese
"Library" verwendent, zu kontrollieren.
Publikationen:
Qualitätsmanagement in der ABAP-Entwicklung,
Why we should take care about clean code
ABAP, Java, JavaScript
GitHub
Qualitätsmanagement in der ABAP-Entwicklung,
Why we should take care about clean code
ABAP, Java, JavaScript
GitHub
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Also, ich arbeite derzeit mit der SolMan-Variante und bin sehr zufrieden. Es gibt für die Produktivsetzung nur einen Transport und fertig. So kann man nichts vergessen, der Status eines Changes ist immer ablesbar, etc.
Ralf
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Seite 1 von 1
Vergleichbare Themen
1
Antw.
Antw.
3522
Views
Views
1
Antw.
Antw.
1925
Views
Views
1
Antw.
Antw.
5610
Views
Views
Netweaver 2004 MINISAP Basis: Fehlermeldung Transportsystem
von Tron » 18.08.2007 11:50 • Verfasst in Tips + Tricks & FAQs
von Tron » 18.08.2007 11:50 • Verfasst in Tips + Tricks & FAQs
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1087
vor 2 Tagen von DeathAndPain 4 / 1087
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1087
vor 2 Tagen von DeathAndPain 4 / 1087