Thanks, this is what I think we are looking for. I'll take a peak at iProjects as that appears to be the ticket. We would just need to convert everything over to iProjects and commit the iProjects to our remote Git repository.
Found this which seems to have a good overview of it:
https://www.ibm.com/developerworks/rational/cafe/docBodyAttachments/3322-102-1-6833/RDi_Remote_Systems_Explorer_i_projects_working_offline.pdf
If there is any better documentation (or preferably training videos) let me know.
-----Original Message-----
From: Arco Simonse [mailto:arco400@xxxxxxxxx]
Sent: Thursday, October 26, 2017 2:04 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: Git for RPG source code management
Hi Matt,
We are doing something similar as you want to do. Not with Git, but with SVN. However, the principal is the same.
For years now the source in our SVN repository (on a non IBMi machine) is leading. We have iProjects defined for every single production sourcelibrary on the i.
We have source, object and data libraries. So say for example PROD1SRC, PROD1OBJ and PROD1DTA.
The iProjects for the sourcelibs are checked in to SVN completely, including the projects .ibmi folders in which the metadata is stored (source properties like membertext, ccsid, sourcefile lenght etc).
The production iProjects live in the svn trunk area.
All developers (ehm, we are with two and sometimes a consultant) check out the iProject for the sourcelibrary they have to work on. In practice that means that all iProjects are always checked out as a working copy in the developers RDI workspace. They push that back to the i, but to their own sourcelibrary say DEV1SRC.
If something needs to be developed or changed, we decide if we just make the change directly in that working copy (tied to the svn trunk), or when the change has a bigger impact we will create a branch for it so that the trunk is not affected until the development has been completed.
The developer has also a copy of the production object an data libraries as DEV1OBJ, DEV1DTA. (This is a simplified picture, we have a custom script that creates these libraries from the production libraries and makes a whole lot of changes) When the developer works on his changes, he also creates a modification script in which the necessary steps are defined to (re)build te tables, programs, etc.
After he finishes the work, he commits to the central repository, including the modification script.
To get these modifications into test and production, we have created separate RDI workspaces for test and production, in which we have working copies of the iProjects. We sync and update them with the repository changes, push the changes to the i, and run the modification script. Other developers can do the same to update their development environment with the changes of the colleague.
This is (very simplified) how we do it. It is not ideal, but over time we got used to it, and we can work this way because we have a small development team.
Many times I have considered to migrate our sources to the IFS, but there is one showstopper that withholds me from that. If a program module is created from an IFS source, it does not show the source reference and change date/time from which it is compiled as we now have with QSYS based sources.
Best regards,
-Arco
2017-10-25 20:24 GMT+02:00 Matt Olson <Matt.Olson@xxxxxxxx>:
All,
I've read this over: http://yips.idevcloud.com/wiki/index.php/PASE/Git
However, it seems to want the Git server running on the IBM i.
We already have a Git Server (VSTS/TFS Online). We don't want another one.
What would be the steps to store all our source code on a remote Git
repository so that we can get all the advantages VSTS / TFS provides
you (code reviews, source code check-ins to bug/workitem linking,
sprint planning, global source code searching).
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
http://amzn.to/2dEadiD
midrange.com
