5 ms·

Upvoted for the retraction. Personal opinions on best practices: - If you have multiple components to an application, whether frontend/backend or microservice

Upvoted for the retraction. Personal opinions on best practices: - If you have multiple components to an application, whether frontend/backend or microservices, put them all in the same repository by default. It is so easy to split them apart again after your team grows to the point where it matters, but before that point you will need to carefully coordinate merging PRs to multiple repos, and sometimes rolling them back, and it is so easy with a small application monorepo. You can just store git’s “tree hashes” in s3 and check if they changed when deciding whether to build and deploy, it's not hard. - If you're versioning, a version.txt file at the root of the versioned content is your friend. Have a {subproject_name}-v1.6 branch, you tag commits on that branch v1.6.3-rc1, rc2, ... automatically with CI/CD, until you tag one RC as a release when you release it. - Everyone merges into main, you cherrypick from main out to those other branches. This keeps the graph clean. When you cut v1.6 you decide whether your next project on main is v2.0 or v1.7. - Feature toggles are your friend, see Rod Hilton’s Three-Flow[1]. Just clean them up when you release! - with about a day's involvement in CI/CD, the `main` branch can have a `k8s/` folder with subfolders for each of your deployment environments. You want to deploy something to prod, just update a version number in `k8s/prod` and merge to `main`. This is even a little simpler than Three-Flow and you can very precisely answer when something was shipped. - folders `rfc/` and `docs/` and `issues/` at the root level would be amazing but I can't get any company to actually do them. One stop shopping! Why not? Once `main` is authoritatively central, it becomes a great place for these things, just the same as you use it for `k8s/prod` and `k8s/dev`. - The underlying point of all of this is to make sure that everybody merges their code every day. If that would break something, put the breakage behind a feature toggle. If it's a config file that doesn't have feature toggles, run the C preprocessor on it or invest in Dhall or some other hack. Do whatever you can so that there is one big conversation happening, and everybody is collaborating. The worst is when you have these huge merge conflicts, the second worst is when you have been doing a lot of work and someone else sweeps it all away before you merge, "oh I didn't see you working on that so I solved it in this inferior hacky way." 1. https://www.rodhilton.com/2017/04/09/a-different-branching-strategy/ https://www.rodhilton.com/2017/04/09/a-different-branching-s...

withinboredom 3y ago
This is almost as bad as the original article... Just deploy any change to main... don't worry about version numbers unless it matters, even then, just version your spec, not your application. If it does matter, deploy all changes to your QA environment. Once you're happy (at the end of a sprint or whatever), tag a commit and release that to production. Need a hotfix? Branch off of your tag, do the thing, and tag that commit and merge it to main. There's no reason for "version" files. you can pull your previous version image and compare the SHA hashes for your new version. If they're different, then deploy the new one (heh, maybe you got some security patches from the base image). Otherwise, no reason to deploy -- or if you have zero-downtime deployments, just deploy it anyway and don't worry about comparing hashes or whether or not something changed.
- alkonaut 3y ago
  Any release I have made whether it's to a package manager or an app store or a windows app etc has had to have not just versions for the product but also some times exact versions for individual files (e.g. Traditional Windows installer apps where screwing up the versioning on even one file is a huge mistake that might prevent the next deployment from working toe to downgrade rules.) I have spent a lot more time in my life on thinking about "versioning schemes" than I have "branching schemes" due to this. E.g. windows files and apps don't have SemVer, just a 4 component version, so you really need to think long and hard about the kind of thing whether 1.0-dev should be 1.0.10 or 1.0.1 in order to sort properly over your 1.0-final and so on. A world where you can just "deploy an image" and know it just replaces your previous one and in general one where you can deploy yourself, to machines you control sounds nice compared to making packages which should work at 10k different users and follow the whims of various stores, package managers and installer systems.
  - withinboredom 3y ago
    It's still not any different. Just tag your release in git. No need for versions files. 1.0 matches 1.0 matches 1.0 of all the components. Want to know what version 1.1 is compatible with? You guessed it, 1.1!

withinboredom 3y ago

This is almost as bad as the original article... Just deploy any change to main... don't worry about version numbers unless it matters, even then, just version your spec, not your application. If it does matter, deploy all changes to your QA environment. Once you're happy (at the end of a sprint or whatever), tag a commit and release that to production. Need a hotfix? Branch off of your tag, do the thing, and tag that commit and merge it to main. There's no reason for "version" files. you can pull your previous version image and compare the SHA hashes for your new version. If they're different, then deploy the new one (heh, maybe you got some security patches from the base image). Otherwise, no reason to deploy -- or if you have zero-downtime deployments, just deploy it anyway and don't worry about comparing hashes or whether or not something changed.

alkonaut 3y ago
Any release I have made whether it's to a package manager or an app store or a windows app etc has had to have not just versions for the product but also some times exact versions for individual files (e.g. Traditional Windows installer apps where screwing up the versioning on even one file is a huge mistake that might prevent the next deployment from working toe to downgrade rules.) I have spent a lot more time in my life on thinking about "versioning schemes" than I have "branching schemes" due to this. E.g. windows files and apps don't have SemVer, just a 4 component version, so you really need to think long and hard about the kind of thing whether 1.0-dev should be 1.0.10 or 1.0.1 in order to sort properly over your 1.0-final and so on. A world where you can just "deploy an image" and know it just replaces your previous one and in general one where you can deploy yourself, to machines you control sounds nice compared to making packages which should work at 10k different users and follow the whims of various stores, package managers and installer systems.
- withinboredom 3y ago
  It's still not any different. Just tag your release in git. No need for versions files. 1.0 matches 1.0 matches 1.0 of all the components. Want to know what version 1.1 is compatible with? You guessed it, 1.1!