@dantelmomsft John and I met, and we thought about pushing to production whenever there is a push to main branch, plus the manual dispatch. WDYT?

@dantelmomsft John and I met, and we thought about pushing to production whenever there is a push to main branch, plus the manual dispatch. WDYT?

this how I see this:

1. CI pipelines

   • App CI: triggered on each commit (or PR) on a dedicated develop branch (today this branch is the main unfortunately). Such branch is linked to a dedicated dev environment. The CI pipeline should also contain some smoke tests on dedicated dev env. This is the purpose of the current app-ci.yaml
   • Infra CI: like the above one but it's triggered only on infra folder changes and will validate the bicep code. It should also redeploy the whole infrastructure, restart the app and run smoke tests. This is the purpose of the initial infra-validation.yaml I've created ( please bring it back :-) )

2. Daily/Nightly build pipelines

   • scheduled infra+app deployment on dedicated environment. Basically it brings together App CI and Infra CI tasks + more functional/performance tests. It could run against the same CI dev environment, or using a dedicated staging environment scaled up/out. The current template-validation.yaml you've created it's a good first step, but we should try to avoid job duplication across pipelines, I see the opportunity to use github pipeline reusable templates here.

3. App Release pipelines

   • Code Promotion: on-demand pipeline which will take care of automating/orchestrating code release (maven release + react npm release). It creates the release tags and deploy the binaries on the binary repository (jar repo, container repo).
   • Production Deployment: Triggered on tag creation will deploy infra+app on a dedicated production environment and run full tests suite against it.

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.