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).
midrange.com
