Moving to Git from any non-distributed source control management system, not only change the tools and the commands set we know but also change the whole perspective of workflow in terms of development and testing scope. Git provides easy and fast ways to develop in feature branches mode, means that each developer works in encapsulated environment where he is encouraged to get the latest changes from a central branch from time to time and provide his stuff when it’s ready, stable and done by any definition of “done”. This approach empowers the developers significantly while adding the quality responsibility aspect.
In order to produce the highest benefit from Git - there is a prerequisite to adjust your working mode and provide the proper test automation scope to support it.
We in SAP HANA Cloud Portal successfully implemented and calibrated such model during the last period that I would like to share.
Who are we (HANA Cloud Portal DevOps)
HANA Cloud Portal DevOps team is responsible for all end to end development processes, tools, dev and production environment and all systems landscapes. We are taking the wheels of build, deployment, automation and runtime responsibilities for all aspects. Our DevOps team successfully implemented and support the ongoing process in order to provide fast, agile, stable and robust development environment.
In this blog – I will discuss about the following topics:
- QBS: Quality Before Submit
- Git branching
- Qos: Quality on Submit (just in a nutshell and a reference to dedicated blog)
- Tests Automation scope to support all above
QBS: Quality Before Submit
What is it? QBS is end-to-end SW development quality process that provides private testing env on a specific feature branch before merging it to a main branch. The process is running in the background so there is no need to waste time in testing.
The main motivation is to have a stable automation tests cycle that runs BEFORE the merge to the main feature branch where it runs.
QBS provides central stable production-like environment unlike normal push / merge to the main branch where you can break the process and fix after that. In addition to that – this process is being triggered manually and on demand by the developer and allows the developer to keep coding and not wasting time with manual testing on his own feature branch. QBS allows choosing the relevant scope for testing.
Triggering QBS process: The process is Jenkins CI based using jobs with parameters. Parameters are injected via manual form that being filled in by the user. The parameters are:
- Git Branch: Taken dynamically from central Git repository using Git Java API (JGIT).
- Reference System: fixed list of systems that will be deployed by the relevant built artifacts.
- Cycle: The cycle mode we want to test. Can be smoke test (short), Acceptance (long). QBS before push to main branch must be in in Acceptance mode. it all runs on top of the deployed system (section above).
Now you can wait for the mail notification. Everything is running in the background. The mail notification contains all relevant data from the cycle including logs and analysis from different types of tests.
Git Branching
One of the most important use cases in Git is the branching model. It’s fast, easy and requires no additional syncs and storage spaces like other SCM systems. Therefore – branches are being created for each backlog item or a bug.
While development – each branch merged into “dev” after green QBS and can be deleted after that. The main goal is to keep “dev” in a green state.
There is an automatic nightly cycle (regression) while green results are indicated as OK to merge into RC (release candidate). In that way we have:
- Continuously stable release for deployment in any time (prerequisite for continuous delivery).
- Development branch (dev in our case) is always open – no dev freeze.
Validation can run periodically on RC branch. In case there is a bug – it can be fixed and pushed to RC and DEV. When you are ready you can deploy this content after you validated the needed content inside.
Right after that there are the following processes:
- Deploy productive systems.
- Merge to master branch (as the deployable branch by Git core philosophy).
- Tag your repository (V-<VERSION>) so you can always go back easily to any specific version.
In case there is an emergency hot-fix – “hotfix” branch will be created based on master. Fix will be pushed to hotfix, master and dev.
QOS: Quality on Submit
QOS is End to end SW development quality process that provides instant feedback and transparency to the development teams. More info about QOS can be found in my previous blog.
Tests Automation scope and Git
Here is a diagram that summarize the while topics above where connecting Git and automation scope.
In a nutshell - QBS before (Feature Branch) + QOS after (Dev Branch) = Winning End to End quality process.
This is one of our main best practices. Please feel free to contact me for any question or follow me @KorenNir. or http://www.linkedin.com/in/nirkoren
- SAP Managed Tags:
1 Comment
