Guzzle Deployment Roadmap - ja-guzzle/guzzle_docs GitHub Wiki

for the Guzzle

1. We are working on finalizing the versioning and generating of the binary on Weekly basis. The version will be <>.<>. <>.<< build number - this is global>>
2. Any customer deployment will take a fixed version of binary which the Devt team has released
3. For Singtel or other projects, no customization shall be done directly on framework - we want to go via Guzzle devt team to make the changes to all the scala code
4. We plan to provide hooks thru which new code can be overlayed in core functionality like how catch up works, or how some of the ingestion works or even checksum. This is in progrses
5. There is already some support of external classes/libraries for streaming module. but there are no hooks /entry point for others
6. Jenkins may not be relevant for small customer where the final code build is deployed and there is no further automation required.
7. Sames goes for TA of the framework using cucumber is no relevant if the there are no changes hapening in Guzzle. They should do the recon and regression using Tractability/recon module But both of above points will be deployed for customers gradually where we expect the framework will be customized beyond standards hooks variable Also TA may be deployed for some customer who have complex business rules and they want sophisticated test automation framework (as working with Recon can be tricky for testing complex business rules)

Proposed versioning and branching strategy:

1. New features will be developed by creating feature branch out of develop branch and when feature development is completed, feature branch will be merged back into develop branch
2. Daily test automation (jenkins) pipeline will consider latest changes in develop branch and test all features (including new features)
3. When release tag needs to be created (weekly or at the end of the running sprint), we can merge latest code from develop branch to master branch and create a tag in a repository. Guzzle binaries will be rebuilt from code in master branch and copied to some directory (or git repository) where all released binaries will be stored into sub-directories with name similar as tag name (binary name can also include name of tag as a suffix like ingestion-<m.n>.jar). Tag name will have major and minor version number.
4. Creating release tag can be semi-automatic. Creator of release tag needs to provide tag name(release version number) and git commit id and invoke a script. Script will do all necessary tasks needed to create release tag as per mentioned in point 3
5. Jenkins pipeline can be updated to copy daily build binaries to some directory (or git repository), where all binaries will be stored into sub-directories with name similar branch name. Only latest nightly build binaries will be maintained
6. Binaries from the release tag will be deployed manually to the customer environment. If some issues are found with binaries in release tag, separate long running branch from release tag will be created. All code fixes (for all current and future issues) for the same release tag(same major and minor version number) will be added to that branch. Once issues are fixed, release tag will be created with same release tag including incremental fix number (like if original tag is 1.3, release tag with fixes will have 1.3.n, where n will be incremental version number). This branch can be called release tag branch
7. There will not be separate customer specific branches. Fixes will be included in the release tag branch and incremental release tag will be shared with all customers
8. There will be separate jenkins pipelines for each release tag branch. We cannot run two pipelines in parallel in the same environment (as they share same set of resources). Ideally jenkins should be running centrally outside of HDP environment and there should be separate environments for each release tag branch. Then jenkins pipeline should run testcases remotely in each environment.