All source code will be stored in a git repository.
If developing customizations locally outside preferred Life Cycle build place (where all builds and sanity deployments are made automatically by a simple process in the LE portal), the IFS cloud released source code need to be cloned to a local git repo, where customizations can be developed using IFS Developer tools.
The first build is made on the entire code base in git.
After that only deltas of changed files are checked out from git an placed in a separate delivery folder. This folder is first converted to a partial build structure (including any changed library artifacts) and is then referenced to from the build_home to compile the new code.
Two ways of handling customizations in git repositories.¶
One common git repository¶
One git repository is used to keep all the code. When a new Service update or release is to be applied the new service update code base from IFS release git repository need to be merged into the local git repo. This is done using the IFS Update Analyzer tool. When the merge is complete a normal delivery delta check out can be made/compiled and delivered.
Separate the RnD code from customized code in two git repositories¶
The RnD code is kept in a separate git read only repository. The customized code will be stored in a separate git repository.
When a new release or service update is to be applied to an environment, the contribution from the IFS release git repository code is copied to a delivery first, then the modified changes on the customization will be added to the same delivery. To identify which files are to be updated due to changes in the RnD code, the IFS Update Analyzer tool will be used pointing to three git repositories. The old version of release, the new version of the release and then the customization repository. The analyzer will use the customization repository as key when comparing differences, so the comparison will only compare relevant files from the three repositories.
From IFS Cloud 22r2 this will be the Build Place way of handling git repositories.