> not clear what code has and has not been deployed
You can have your production machines deploy from specific branches. In other words, master is the development branch, some-version-branch is the production branch. You can also do it vice versa. You can use tags. Lots of solutions.
> code is not explicitly validated (automatically, manually, on a build/test lab)
If you use the structure above, you wouldn't commit to a production branch unless you did that. Another solution is to force validation/testing using hooks before allowing a commit to a production branch on your development machine.
> and it isn't clear who triggered the release.
Not sure what you mean here ... every commit is recorded, so you always know who did what.
I guess it depends on your deployment system, if there is an automated system watching that branch on a central repo, you assume any commit is rolled out and who ever pushed triggered it via commit.
Comments
Not if you structure your repo correctly.
> not clear what code has and has not been deployed
You can have your production machines deploy from specific branches. In other words, master is the development branch, some-version-branch is the production branch. You can also do it vice versa. You can use tags. Lots of solutions.
> code is not explicitly validated (automatically, manually, on a build/test lab)
If you use the structure above, you wouldn't commit to a production branch unless you did that. Another solution is to force validation/testing using hooks before allowing a commit to a production branch on your development machine.
> and it isn't clear who triggered the release.
Not sure what you mean here ... every commit is recorded, so you always know who did what.
I guess it depends on your deployment system, if there is an automated system watching that branch on a central repo, you assume any commit is rolled out and who ever pushed triggered it via commit.