I'm working at a small company with just a two-person development team, and we currently lack solid protocols for version control and continuous integration/continuous deployment (CI/CD). Our team is mostly composed of talented scientists who are building tools for research and development as well as quality assurance.
I want to leverage the flexibility I have here to learn more about version control processes and tools without needing to reinvent the wheel. Our tech stack consists primarily of Python with PyQt for developing Windows desktop applications.
Here's the workflow I have set up so far:
- Versions are tracked in a .py file, which is referenced by my PyInstaller .spec file and my main.py to update the version displayed on the title bar and throughout generated files.
- I've scripted a version bump command that activates on `dev` once I'm ready to release. This allows me to specify whether I want to increment `major`, `minor`, or `patch` versions.
- The script also tags the release on the main branch and subsequently triggers GitHub Actions.
- The GitHub Actions take care of the build process and create a release along with a changelog that summarizes the commits between version tags.
I'm also trying to implement a Git Flow branching strategy, although I haven't added `release` branches to the process yet.
Here's a rough sketch of my release workflow:
```bash
* Merge main back into dev - sync release v1.2.0 (HEAD -> dev)
|
| * v1.2.0 - release tagged on main (release created on GH here) (tag: v1.2.0, main)
| |
| | * Merge dev into main for release v1.2.0
| |/
| * QA complete on dev (dev)
| * Merge feat/fix into dev
| |
| | * Implement feature X (feat/fix)
| | * Branch feat/fix created from dev
| |/
* Dev baseline before feature work
```
I'm curious about how to further automate these processes. How are others managing version control? Is using a .py file to track versions adequate in a professional setting?
Could I delegate more tasks to GitHub Actions, perhaps by creating a `release.py` or `.sh` script that could automate everything?
1 Answer
You bring up some interesting points! First off, consider whether you actually need semantic versioning (semver). It's often helpful for API or package development, but if your software is mostly internal, you might not need to follow that strict format. We just use a date-based versioning system which automatically generates our version numbers during builds. This way, our team always knows the exact build date!
Also, if you do decide to use semver, you can keep it separate from your code. For example, just tag your version releases in the repository instead of managing them in a file. Then, configure your CI/CD workflow to kick off the build process whenever a release tag is created. This simplifies the versioning process and keeps your main code clean from tracking numbers.
That’s really helpful! So you’re saying I can focus on just tagging releases while letting the CI/CD handle builds and versioning? It sounds like a clean way to manage things without cluttering my scripts with version details. Thanks!