Branching strategies
Not sure I agree with the suggestion of feature-branching. I think the guidance should state trunk-based development first. Still use a pull request workflow as long as those feature branches are short-lived. If you can guarantee features are going to very small, then feature branching is fine. If not, feature branching can easily turn into long-lived branches which we must avoid.
The guidance should say something about making a conscious choice about the strategy employed, weighing up pros/cons and making sure consensus is gained in team, with regular checks questions whether strategy still makes sense.
Lots of strategies here - https://trunkbaseddevelopment.com/
Skeleton projects
Love the idea of this. I like how updating skeleton project is left to the last user. May be hook up with cloud platform team as well
If we can get our onboarding process right, so that teams get lots of the non-functional things they need "out of the box" (e.g. CD pipeline, alerting, dashboard, logging ...)
https://mojdt.slack.com/archives/C3F8L6XQU/p1571751067061500?thread_ts=1571747656.059900&cid=C3F8L6XQU
A skeleton project could have the "out of the box" cloud platform things. An alternative to last user is have a rotating owner, then formal handover to next person. Deployment on cloud platform would feature a hello world, details about the skeleton, etc... might be overkill - not sure.
Build artifacts - docker images
Can we put details of the registry? Point to some internal examples or best practice guidance
Quality and security checks
Getting these checks early into the software dev life cycle is thing all teams should be doing now. I think the message about quality in the dev stage is very well understood, security less so - that's why there's initiatives like "shifting left on security". It'd be good to get more advice from security team on the automated tools developers can be using to achieve outcomes and common ways to measure security quality.
Sonarqube
Not sure if we should be stating a product name. Should section name be about the problem / process / thing we're trying to do? What are must-have checks in a build pipeline that products like Sonarqube give us? There's similar companies offering overlapping products with slightly different feature sets, e.g.https://www.sonatype.com/
Show less
Branching strategies Not sure I agree with the suggestion of feature-branching. I think the guidance should state trunk-based development first. Still use a pull request workflow as long as those feature branches are short-lived. If you can guarantee features are going to very small, then feature branching is fine. If not, feature branching can easily turn into long-lived branches which we must avoid. The guidance should say something about making a conscious choice about the strategy employed, weighing up pros/cons and making sure consensus is gained in team, with regular checks questions whether strategy still makes sense. Lots of strategies here - https://trunkbaseddevelopment.com/ Skeleton projects Love the idea of this. I like how updating skeleton project is left to the last user. May be hook up with cloud platform team as well If we can get our onboarding process right, so that teams get lots of the non-functional things they need "out of the box" (e.g. CD pipeline, alerting, dashboard, logging ...) https://mojdt.slack.com/archives/C3F8L6XQU/p1571751067061500?thread_ts=1571747656.059900&cid=C3F8L6XQU A skeleton project could have the "out of the box" cloud platform things. An alternative to last user is have a rotating owner, then formal handover to next person. Deployment on cloud platform would feature a hello world, details about the skeleton, etc... might be overkill - not sure. Build artifacts - docker images Can we put details of the registry? Point to some internal examples or best practice guidance Quality and security checks Getting these checks early into the software dev life cycle is thing all teams should be doing now. I think the message about quality in the dev stage is very well understood, security less so - that's why there's initiatives like "shifting left on security". It'd be good to get more advice from security team on the automated tools developers can be using to achieve outcomes and common ways to measure security quality. Sonarqube Not sure if we should be stating a product name. Should section name be about the problem / process / thing we're trying to do? What are must-have checks in a build pipeline that products like Sonarqube give us? There's similar companies offering overlapping products with slightly different feature sets, e.g.https://www.sonatype.com/ Show less