ILE Quellen IFS vs Source Files

[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

1. 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.)
2. 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)
3. 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).
4. Falls ihr umstellt: Mit welchem Schritt würdet ihr anfangen?
5. 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...eas-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.

[Fuerchau]

Ein Einstieg ist sicherlich einfacher als ein Umstieg.
Allerdings könnte der Einstieg in VS durchaus von Vorteil sein, denn RDi lässt ganz schön zu wünschen übrig. Ins besonders was das berühmte Intellisence angeht, das Autovervollständigen.
Unter bestimmten Bedingungen klappt das nämlich überhaupt nicht, da die Syntaxanalyse nicht erkennt, dass da u.U. Namen gepromptet werden müssen.
Bei qualified DS wird z.B. immer gleich der Name der DS als auch gleich aller Subnamen geprompted.
Wenn ich viele DS habe die in den erst 5 - 10 Buchstaben identisch sind, würde mir der DS-Name da reichen, denn nach dem Punkt könnte ich ja den 2. Prompt bekommen.
Da ist VS bestimmt besser und daher eben auch schneller. Denn beide, VS und RDi müssen die Datei ja sowieso lokal runter laden.

[Pikachu]

Wie empfiehlt IBM eigentlich die Quellen ins IFS zu umzuziehen und alles weitere?

[dschroeder]

Wie empfiehlt IBM eigentlich die Quellen ins IFS zu umzuziehen und alles weitere?

Das ist eine sehr gute Frage!

Ich habe darauf bei Vorträgen oder in direkten Gesprächen bisher unzureichende Antworten bekommen. Das alte Projekt BOB "Better Object Builder" (Bitte nicht verwechseln mit dem neuen KI-Projekt Bob!!) sollte das ermöglichen. Wenn ich nach Details gefragt habe, wie z.B. "wo bleiben denn die Source-Beschreibungstexte?" hieß es in etwa:
- Die meisten Programmierer sind nicht auf die Texte angewiesen
- Wenn mein Gesamtprojekt so groß ist, dass ich auf die Texte nicht verzichten kann, dann ist mein Gesamtprojekt eben nicht optimal.
=> Das hilft mir natürlich nicht weiter. Meine Gesamt-Anwendung ist eben so wie sie ist. Es nützt mir nichts, wenn man mir sagt, sie müsste kleinteiliger geschnitten sein.

[BenderD]

3. Bei uns umfassen Änderungsprojekte oft mehrere Member, die gleichzeitig angepasst werden müssen und miteinander korrespondieren müssen.

m.E. liegt hier das Problem!. Klingt für mich so, dass ihr immer noch one-procedure-module macht => das führt zu enger Kopplung und breiten Parameterschnittstellen (deshalb auch die vielen Copystrecken?).

D*B