But of course, seeing the world through TDI-colored glasses mean that my view is indeed a bit colored...
As I've noted before, I organize projects in a particular way that has served me well for years:
- A Project Folder (the one that Eclipse gives you in your workspace and that shows up in the CE). In general, apart from running git from this folder, I tend to leave everything being managed by Eclipse alone.
- And a Solution Folder (with the same name as the Project itself and found in the Solution Directory).
- Furthermore, all filepaths in the solution are relative and reference files in the Solution Folder, or its sub-directories. Filepaths also have only forward slashes instead of backslashes.
As you may have gathered from my description above, there needs to be two git repositories: one for the Project Folder and one for the Solution Folder. The Project Folder is the source while the Solution Folder holds the deployment assets, including properties and other support files and folders. Which also means all Property Store filepaths should be relative (and with forward slashes). As noted above, you may have custom jars for your solution. Simply drop them all into a folder , e.g. CustomJars, in the Solution Directory. You let TDI know about this folder via the com.ibm.di.userjars property in solution.properties which is found in your Solution Directory. Be sure and make this a relative path too.
This is the first step. Then comes the tricky bit.
Since TDI source files (*.assemblyline, *.connector. etc.) are all XML encoded, merging changes when two or more people edit the same source asset can be a challenge. For one thing, there are plenty of XML tags in these files that are only for internal use, like <ModTime>. So you end up having go through the files, comparing known tags and script snippets. Not ideal.
Which is why we kept to a strict git regime: push to the trunk (i.e. master, with no branches) using pull requests for peer review, and agreement on which files we each were working on. Not ideal, but until we can get a VSCode extension that handles this for us, it's the best you can do. Of course, editors like VSCode make it easier to compare changes and accept/reject as desired.
Once source management (and sharing) is organized, it then comes down to organizing work. Here is where Scrum, the brainchild of Ken Schwaber and Jeff Sutherland, both Agile Manifesto signatories, comes in.
Their original vision of Scrum is as a flexible, adjust-as-you-need methodology that really dictates only a few things:
- Cross-functional, empowered teams
- Short work cycles with clearly defined outputs
- Open and continuous communication