Develop true CI/CD Pipeline.

pryorda commented 5 years ago

I feel that we we should just be merging to master and tagging the commits with the version. I'm not sure if we need to go release branch -> master.

Jc2k commented 5 years ago

Totally agree!

Jc2k commented 5 years ago

So how shall we go about this? I guess its mostly about process. Does anyone have any particular requirements?

User submits PR
Travis automatically lints + runs tests (including a test of the Docker image)
If tests pass a code coverage result is submitted to codecov.io, and it will comment on PR
One of us does code review
When all of this passes we merge to master
We may merge multiple PR's
We tag master + push
CI etc will run for the tag, but it should pass as we won't change anything
New containers are build and published

Questions:

Should we tag in git land or "draft a new release" in github land (https://github.com/pryorda/vmware_exporter/releases/new)? (I like the idea of doing it in github land, but right now there are manual version bumping steps).
How do Docker images get published now? (manual or cloud.docker.com or ....)
Do we / should we publish an image of master? (i think we should)
Do we / should we publish an image that points to the lastest stable tag? (i think we should)
Do we / should we publish each git tag as a docker tag? (i think we should)
If we did publish to pypi, would we want to build this into the CI/CD pipeline? (on the fence, would have to have a dedicated pypi account at the very least)

Whats the simplest viable change we can make? We could start merging to master immediately, and keep the release branch a way of reviewing the version bump and changelog updates?

pryorda commented 5 years ago

Edits below:

User submits PR - Create a template and we manage the version.
Travis automatically lints + runs tests (including a test of the Docker image)
If tests pass a code coverage result is submitted to codecov.io, and it will comment on PR
One of us does code review
When all of this passes we merge to master and auto bump version.
I prefer single topic releases if possible.
We tag master + push
CI etc will run for the tag, but it should pass as we won't change anything
New containers are built and published, currently docker hub handles this based on any commit to master + tags.

Questions:

I think we should only draft releases for Major and Minor releases. Is there a way to automate this? Could something pull in our change log and publish the updates?
Automagically via the integration to Github based on master as latest and tags.
Master should equal latest in my opinion, we could have the two tags if you want. These should always be the same if possible?
Yes
Yes
I definitely think we should publish to pypi and create a dedicated account and use an api key if possible for the release.

We should build templates like: https://github.com/devspace/awesome-github-templates

All of this should be automated to the fullest.

pryorda commented 5 years ago

https://github.com/semantic-release most of these tools should help with some of these tasks.

pryorda commented 5 years ago

Looks like we've achieved greatness. It now auto bumps versions based on commit messages. @jc2k @dannyk81 do you guys see any issue with what I did?

pryorda commented 5 years ago

Going to close this out as I think we are pretty CI/CD'd

pryorda / vmware_exporter

Develop true CI/CD Pipeline. #51