vdel
commented
6 years ago For me the main part of a release is to publish docker images (that are identifiable: a git tag as the root key is great), and soon after other resources, such as a new helm chart version; and maybe a docker-compose?.
Agreed.
The changelog is a good part, and we later will have to think about public vs internal changelogs.
Agreed, I think that actually even internal changelog can be refined (lightened) by hand to be readable. I guess public change logs are even more lightened.
The current implementation doesn't guarantee that the computed changelog corresponds to the commit pointed to by the created release.
Indeed, this has been fixed.
What we release is a key question, and asking for a branch name seems fragile: it is a moving target. Asking for github to create the tag helps to be up-to-date, but we then take the risk to be too updated: release a too recent commit we didn't want.
I think this is not a concern anymore as I have fixed the point above.
but releases are not only for Continuous Deployment: we have on-premises releases too.
Well, to me, a release is a snapshot of your software at a given time. If your soft is intended to run on both the cloud and on-premise, then the release must contain both helm packages for example. To me, an on-prem release should also correspond to a cloud release. And both MUST have been deployed on some pre-prod or staging environment at least for QA. That's why we have to specify a branch when releasing, because for now branches and deployment are correlated.
The current implementation relies on deployment tags, which may not be future-proof, and strongly correlate deployment and releases.
See above: I think deployment and releases MUST be correlated. That's the branches and the environment that should not be correlated.
Ideally, we would have one master branch which is plugged in continuous delivery to some staging environnement. I don't you need the notion of release for this (it would be contradictory with the notion of CD).
When you are happy with the current state, you freeze your app and this becomes a release, which can be deployed in other environments.
This follows up on @thomas-riccardi comment in #221 reproduced below:
Regarding the "full release cycle", this needs to be explicitly defined. For me the main part of a release is to publish docker images (that are identifiable: a git tag as the root key is great), and soon after other resources, such as a new helm chart version; and maybe a docker-compose?.
The changelog is a good part, and we later will have to think about public vs internal changelogs.
What we release is a key question, and asking for a branch name seems fragile: it is a moving target. Asking for github to create the tag helps to be up-to-date, but we then take the risk to be too updated: release a too recent commit we didn't want. The current implementation doesn't guarantee that the computed changelog corresponds to the commit pointed to by the created release. The current implementation relies on deployment tags, which may not be future-proof, and strongly correlate deployment and releases, but releases are not only for Continuous Deployment: we have on-premises releases too.
An alternative approach would be to let users create and push git tags, and give that as input to dmake release, which would publish "released" (and at first rebuild/test) docker images.