ILE Quellen IFS vs Source Files

[Andreas_Prouza]

Hi Malte,

zunächst mal gratuliere ich für den mutigen Schritt die alten SRC-PF verlassen zu wollen!

@GIT-Branches

Als Richtwert könntest du dir Gitflow ansehen. Hier bekommst du einen guten Überblick wie mit Branches im Git gearbeitet wird.
Ich begleite mitlerweile immer mehr Firmen beim Umstieg. Auch in den Academys an denen ich unterrichte, ist dies mitlerweile pflicht.

Meine Empfehlung: Macht es langsam!
Führt nicht gleich am Anfang das ganze Branchen-Konzept ein, sondern lernt zunächst die Basics und dann Schritt für Schritt.
Es ist wichtig am Anfang bewusst Fehler machen zu dürfen, um die ganzen Vorteile von Branches sehr schätzen zu lernen.

@GIT Repo Server

Verwendet ein Webbasiertes Repo wie Github. Es gibt einige Open Source Tools wie Gitlab, die lokal installiert werden können.
Ich bevorzuge hier Gitea oder Forgejo welche ein Fork von Gitlab.
Außerdem sind diese auch auf einer POWER Architektur unter Linux installierbar. Ich persönlich verwende am liebsten eine simple Linux VM auf X86 Basis für alles was außerhalb der IBM i ist. Da gibt es weniger Probleme mit Kompatibilitäten.
Forgejo hat auch keine bereiche wo dann doch noch Lizenzkosten anfallen, deshalb ist dieser meine Empfehlung wenn man hier Kosten sparen möchte.

Die Verwaltung und Handhabung der Repos geht hiermit viel besser und ist somit Pflicht!


@Abhängigkeiten & Automatisierte Builds

Ich hab ein Open Source Projekt (OBI) für diesen Punkt entwickelt, welches auch als Extension im VSCode Verfügbar ist.
https://marketplace.visualstudio.com/items?itemName=andreas-prouza.obi
Ziel: Wenn ich eine PF, LF, DSPF, SRVPGM etc. ändere, sollen automatisch alle abhängige Objekte mit umgewandelt werden und das mit den richtigen Befehlen in der richtigen Reihenfolge.
D.h. der Developer soll sich nicht mehr darum kümmern müssen.

@Source Beschreibungstexte

Diese sind mit OBI ebenfalls weiterhin vorhanden. (Siehe Bilder im Link oben)

@Cloud Development

Heute gibt es viel zu viele Abhängigkeiten am lokalen PC:
* Netzwerk verbindung zuden Servern (FW etc.)
* Installation diverser Software (Java, Git, Python, vscode, extensions usw.)
* uvm.

Es entsteht also viel Aufwand PCs der Entwickler einzurichten.
Dafür gibt es ebenfalls ein freies Tools wie z.B. Coder (coder.com), das hier einem Unterstützt die Entwicklung zu zentralisieren:
https://github.com/andreas-prouza/blog/issues/8

@Deployment

Hierfür habe ich ebenfalls ein Open Source Projekt i-Releaser (https://github.com/andreas-prouza/i-releaser).
Ist ein Workflow System.
Du musst also die Steps definieren und die Tasks die er in jedem Step auszuführen hat.

Ich hoffe das hilft weiter. Lass es mich wissen wenn du mal nähere Infos oder Unterstützung benötigst.
lg Andreas

[dschroeder]

Hallo Malte,
ich finde das Thema "Umstieg auf IFS" hochspannend. Wir überlegen auch immer mehr, ob wir den Schritt gehen sollten. Es sieht ja so aus, als sei zukünftig VSCode für IBM die IDE der Wahl.

Git ist für uns bisher kein Grund, umzusteigen. Unsere selbstgeschriebene Versionierung reicht uns zur Zeit aus. Die Frage, die wir uns immer stellen, ist, ab wann die Vorteile der Umstellung die Nachteile und den Umstellungsaufwand überwiegen.

Deshalb hätte ich mal ein paar Fragen an dich (gerne auch an andere Teilnehmer):

Mit wie vielen Programmen hantiert ein Entwickler bei euch so am Tag? Könnt ihr das gut filtern? (Bei uns sind es meistens so viele Programme, dass nur die Programmnamen nicht reichen. Ich filtere sehr viel über den Beschreibungstext des Members.)
Habt ihr größere Copy-Strecken, die ihr einbinden müsst? (Bei uns sind alle Datenstrukturen, die zwischen Programmen als Parameter hin- und her gereicht werden, in einer sehr großen Copy-Strecke. Wir überlegen, das dann auseinander zunehmen und die Strukturen als einzelne Files im IFS zu speichern)
Wenn ihr mit Git arbeiten wollt: Würde es wirklich funktionieren, mehrere Branches zu machen, in denen ein Source dann mehrfachen Änderungen unterworfen ist? Kann es wirklich klappen, so etwas automatisch zu mergen? (Ich kann mir das einfach nicht so recht vorstellen).
Falls ihr umstellt: Mit welchem Schritt würdet ihr anfangen?
Welcher Zeitaufwand für die Gesamtumstellung erscheint euch akzeptabel?

LG, Dieter

[Andreas_Prouza]

@1
Das Filtern über Beschreibungstexte & Co ist normal kein Problem bei entsprechenden Tools

@3
In Git kannst du einstellen ob der Merge automatisch erfolgen soll, oder ob dieser eine Finale Bestätigung eines Entwicklers benötigt.

@4
Phase 1:
Erster Schritt wäre die Richtung zu definieren und danach die Meilensteine dort hin.
Für die Richtung sollten verschiedene Möglichkeiten erforscht und verglichen werden.
(Vor/Nachteile, Kosten, Flexibilität, Technologie-Offenheit, ...)

Phase 2:
Umsetzung starten

Phase 3:
Einschulung und Testen für die Mitarbeiter

Phase 4:
Go Live

@5
Kommt auf das Ergebnis von Phase 1 an.

[KingofKning]

Interessante Infos, wenn ich bald mein Projekt das Lagerverwaltungsprogramm InfoControl 1001 in Cobol wieder ins Leben rufen werde, werde ich die Dinge bezgl. GIT etc. mal versuchen umzusetzen.
Vermutlich wird es dann die eine oder andere Rückfrage geben ;-)

GG 2018

[Malte]

@Andreas_Prouza

zu dem Repo Server hier haben wir bereits einen Cloud Server in Einsatz.
In unserem Fall DevOps.

Die Empfehlungen zu den Erweiterungen für VS Code werde ich mir dann wenn es soweit ist auch alle noch mal angucken.

@dschroeder






Mit wie vielen Programmen hantiert ein Entwickler bei euch so am Tag? Könnt ihr das gut filtern? (Bei uns sind es meistens so viele Programme, dass nur die Programmnamen nicht reichen. Ich filtere sehr viel über den Beschreibungstext des Members.)
Habt ihr größere Copy-Strecken, die ihr einbinden müsst? (Bei uns sind alle Datenstrukturen, die zwischen Programmen als Parameter hin- und her gereicht werden, in einer sehr großen Copy-Strecke. Wir überlegen, das dann auseinander zunehmen und die Strukturen als einzelne Files im IFS zu speichern)
Wenn ihr mit Git arbeiten wollt: Würde es wirklich funktionieren, mehrere Branches zu machen, in denen ein Source dann mehrfachen Änderungen unterworfen ist? Kann es wirklich klappen, so etwas automatisch zu mergen? (Ich kann mir das einfach nicht so recht vorstellen).
Falls ihr umstellt: Mit welchem Schritt würdet ihr anfangen?
Welcher Zeitaufwand für die Gesamtumstellung erscheint euch akzeptabel?



1. In unserer Haupt LIB sind so mehrere, da wird aktuell viel mit 25 Gesucht um entsprechende Programm zu finden.
2. Da wir leider erst spät mit CopyStrecken angefangen haben, sind wir nun in der Glücklichen Situation das diese alle nicht so groß und schön getrennt sind
3. GIT wärden wir erst im zweiten schritt dann einführen. aber wir arbeiten schon mit anderen Projekte C#, JS, TS, etc. mit GIT in DevOps wenn in der selben datei nicht grade die gleiche Stelle betroffen ist klappt der merg meiste.
Sonst bekommt kann einen merge conflict und muss hier die entsprechenden Änderungen Händisch mergen.
Das passiert aber selten und ist meistens einfach zu beheben.
4. Wir haben jetzt grade test weise ein LIB umgestellt in der wir die Web Service für eine WebShop Anbindung haben. Hier sind ca. 35 RPGs davon 1 Modul und 5 CopySrc drin
5. Hier sind wir noch in der Findung bis jetzt habe ich ca. 2 Tage reingesteckt damit können wir aus dem IFS Kompilieren und auch ein paar ander unser Tools wurde angepasst das diese auch das IFS berücksichtigen.

[Fuerchau]

Da es Git auch OnPrem (Windows/Linux) gibt empfehle ich eher diese Lösung.
Denn wenn die Cloud ausfällt steht das halt nicht zur Verfügung.
Da es immer auch einen lokalen Git im Projekt gibt, zumindest mt VS, wird dieser ja mit dem Remote syncronisiert. Und da ist es besser, den Server im lokalen Netz zu halten.

Und wer weiß, was durch den US-Cloud-Act bei den amerikanisch basierten Servern, die auch in der EU stehen, so alles geklaut werden kann;).

[dschroeder]

Hallo Malte, hallo Andreas,

vielen Dank für eure Antworten.

1. Andreas schrieb, dass das Filtern kein Problem sei über bestimmte Tools. Mir geht es darum, ob ich das direkt aus der IDE (also dann aus dem VSCode machen kann). Zur Zeit arbeite ich mit RDi und unser "Haupt-Arbeitsgerät" ist die Objekttabelle im RDi. Da habe ich die Filter immer offen (bei einem großen Bildschirm kann man das gut machen) und kann da dann relativ schnell durch meine Sourcen navigieren. Unsere Sourcemember sind relativ klein. Aber dafür haben wir sehr viele Member.
Gibt es im VSCode bereits Filtermöglichkeiten, die ähnlich wie in der Objekttabelle des RDi sind?

2. Wir arbeiten viel mit iSphere. Die Suche ist sehr schnell und flexibel. Ich kann nach mehreren Begriffen suchen (auch negativ) und z.B. angeben, dass beide Begriffe in einer Zeile auftauchen müssen. Gibt es eine starke, schnelle Suchen auch im VSCode?

3. Bei uns umfassen Änderungsprojekte oft mehrere Member, die gleichzeitig angepasst werden müssen und miteinander korrespondieren müssen. Wenn ich Teile dieser Programmgruppe zusätzlich in anderen Branches habe, dann kann ich doch nicht so einfach mergen. Das kann ich mir kaum vorstellen. Vielleicht spricht die eine Änderung ein neues Feld in einer Bildschirmmaske an und die Änderung im anderen Branch benötigt ebenfalls ein (anderes) neues Feld in der Maske. Da muss das Ändern und Ausrollen doch extrem koordiniert ablaufen. Das kann einem Git doch nicht abnehmen. Oder verstehe ich da etwas falsch?

[Fuerchau]

Zu 1+2: Es gibt im VS eine Suche über alle Projektdateien, auch mit Mustervergleichen.
Dazu braucht man ein Masterprojekt, das dann auch Subprojekte enthalten kann, die dann alle durchsucht werden.
Am Beispiel eines ERP's habe ich ein Gesamtprojekt, das sich aber in Teilprojekte wie Auftragswesen, Bestellwesen u.v.m., aufteilen lässt, sowie einem weiteren Subprojekt für übergreifende Services.

Das Branch-Handling ist zugegeben sehr komplex, und bedarf natürlich einer gewissen Dispziplin.
Gehen wir von einem normalen Projekt aus, so kann jeder nur einzeln an einem Objekt arbeiten.
D.h., ich arbeite an ProgA mit DSPF A und ggf. weiteren Abhängikeiten, die das Programm betreffen.
Du kannst dann an ProgB arbeiten.

Gemeinsame Ressourcen wie die Datenbank (Tabellen, Views, Indexe, Trigger, Constraints, ...) werden je Objekt gezielt einzeln durchgeschossen, wie ich oben schon mal sagte, und könnten in einem eigenen Subprojekt liegen.

Mit Branches hat das noch nichts jzu tun.
Branches benötigt man für Releases des Gesamtprojektes, bzw. von Teilprojekten.
Dabei geht immer vom Kontext des Projekts und nicht der Objekte aus.

Wenn ich also ein Release V1 erstellt habe, das natürlich gestestet und stabil ist;-), kann ich das in einem Branch V1 fixieren.
Das aktuelle Projekt ist dann weiter das Entwicklungsprojekt.

Treten nun im freigegebenen V1 wider jeglicher Erwartung nun doch Fehler auf, dann behebe ich in V1 den Fehler, kann das dann in Echt als V1.1, ggf. als Branch, deployen.
Gemachte Ergänzungen merge ich dann ins aktuelle Projekt.

Jetzt habe ich also 3 Branches. An die Ableitungen V1, V1.1 arbeite ich erst mal nicht weiter.

Soweit nun die blanke Theorie.
Die Anzahl der Branches wird durch die Anzahl verschiedener Installationen bestimmt. Wenn die Version eines Branches nicht mehr installiert ist, kann ich diesen auch löschen.

Bei selbstprogrammierenden Anwendern reicht i.d.R die aktuelle Umgebung und genau 1 Branch der produktiven Umgebung um schnelle Korrekturen zu ermöglichen.

[Andreas_Prouza]

@1: Erstes Bild in der Doku von der vscode Extension https://marketplace.visualstudio.com/items?itemName=andreas-prouza.obi

@2: vscode hat standardmäßig eine umfangreiche Source-Suche. Hat viele Möglichkeiten und auch Regex.

@3: Koordination ist nicht das wichtigste. Zu Verstehen wie Git funktioniert und wie man es sich für seine Bedürfnisse verwendet ist hier wichtiger.
Das gleiche Problem gibt es auch bei anderen Sprachen und funktioniert.
Am besten nimmt man sich jemandem (entweder intern oder extern) mit dem diese Themen z.B. als Workshop durchgegangen wird.

[dschroeder]

Vielen Dank für die Antworten.

Wenn ich mit einem kleinen Schritt anfangen möchte, bliebe mir doch nur, zunächst die IBM i Erweiterungen für VSCode zu installieren und zunächst mit den Sourcen in Teildateien weiter zu arbeiten, oder?

Jede andere Lösung, die die Sourcen im IFS verlangt, wäre ja ein Riesen-Break, der alle anderen IBM i Programmierer sofort beeinträchtigen würde. Meine Kollegen wollen sicherlich erstmal alle weiterhin mit RDi arbeiten.