Yeah I am fine to scrap the Cannery idea, I can see issues cropping up for us with it.
What do u mean by no version in params?
I’m seeing this right now.
params: ## Which Git revision should this container use? version: HEAD
I agree there’s no reason to not use the
I suggest we use the same names those projects do. I don’t think it makes sense to reinvent terms for what is already in use in two projects we depend on!
canary: our current
tests-passedbranch can be renamed to this.
- beta: our weekly bumps
- release: our stamped, tagged releases
Again, why not use the 6 weeks that Chrome and Ember use rather than 8 weeks? I think there is value in sticking to the conventions others have set up.
I agree with that, except “canary” is an awful meaningless name. I suggest we use “latest” instead as that is actually understandable. If I said to someone “you should be on latest to get those fixes” that is far easier to understand than “you should be on canary to get those fixes”. WTF?
I know they think canary in the coalmine is all clever and stuff, but it is the bad pointlessly confusing kind of clever.
I actually like the analogy, but for different reasons. ‘Canary’ evokes the image of a little bird with fancy, colorful feathers… bit given the chance it’ll pick up your data and fly out of the window with it while pooping on your hand.
Yeah. I have some bad experiences with pet birds.
How about a single branch (mainline) and always shipping that? With proper unit and functional testing, and attention to detail before committing, this would be the nimblest process possible.
No, seriously – if something’s wrong, that should be quickly found, and quickly fixed. If everything is on mainline, a fix if something should escape the barrage of unit tests is only a quick revert away.
We’ve used continuous deployment successfully at IMVU for almost ten years now, and I would not want to go back to branches, at least as long as the target is web.
Latest sounds great!
I actually prefer chrome release style. Not all of us want to ride on master branch (well i do but i believe i belong to a rather small subset of userbase here). Some of us may prefer a well tested release if their forum is huge and cannot tolerrate any downtime.
Agreed. I imagine that many don’t want to risk a broken forum when they click “Update”. The beta and canary branches are for those more inclined to testing and developing, while a stable branch is for people that just want it to work, and work reliably.
I think there is value sticking with the terms other projects have adopted. I’m a big fan of convention and “Canary” seems to be the term people are using for this channel. Why not use what people already know?
Some of us may prefer a well tested release
Why isn’t every commit a well tested release?
Because Git is not a release platform, it’s a tool for developer collaboration.
Yes, you can push between developers with git if those developers are collaborating on a particular feature.
Once you push to general consumption (developers or customers,) it would stand to reason that you have coverage with acceptance tests (easy to do for web apps! check saucelabs or similar) and unit tests (rails has lots of support for this.)
I’ve worked in many places that have used various release branch mechanisms, and it’s always been work to manage those, and developers end up using QA and release branches as an excuse to not write good automated tests. I’ve also worked at a place where each commit to master goes live in front of customers, assuming it passes all automated tests. This site has been around for ten years and has tens of millions of monthly users, and having solid automated testing coverage is a significant asset to the engineering organization and company.
So, again: Why wouldn’t every commit to master be a stable commit, well tested (automatically) and ready for use?
The smaller such commits are, the less likely they are to break, and the easier they are to undo if they end up breaking something. (The four-branches, a-month-to-build-a-release monster processes end up breaking things in production anyway, in my experience.)
So it boils down to nomenclature. You expect commits in
master to be stable and tested, Discourse chose to follow a different branch naming scheme: to wit, tests-passed, which automatically follows master when tests pass.
Is that really such a big deal?
If you have tests-passed, then why do you need all the other beta/release/canary branches? Why are you not confident in test-passed?
Ah, I see, you still believe in the myth of the fool-proof unit test.
This is neither the place nor the time for a debate on test completeness, so I’m not going to pursue this further.
Still, after all is said and done, you do realize that you will be getting exactly what you asked for, right? Canary, if that name even sticks, is a mere rename of the tests-passed branch. Nobody’s forcing you to stick to tagged releases.
Canary usually means a daily build, which is not our intention at all with this channel. I really like @codinghorror’s suggestion of naming it “latest”, it is less scary and properly represents what we mean here. We will still be deploying latest to customers even post v1. Ember, Chrome and Firefox would rarely recommend general population use Canary.
Plus we’ve been calling it “latest” for about a year now, so it reflects the terms we actually use, and what people seem to understand just fine.
There is no such thing as a fool-proof automated test suite, any more than there is a fool-proof release branch system. However, automated acceptance tests plus automated unit tests can test at least as much as a human following a written test plan, but tirelessly, and for each commit. Having built and worked with both kinds of release systems on major products, I would say that the end results of pushing code live ASAP with very strong automated testing beats the end results of using a branch-heavy, delay-inducing “traditional” release process.
I’m offering this perspective from having worked on both, deeply, for a long time. I understand that you have experience with the branch-heavy version, but I don’t see understanding of the alternative. Which is fine; you’re probably a lot more committed to this particular project than I am; all I can do is share pretty hard-fought learnings hopefully for the better good.
I don’t think that having a “latest” and a “tests-passed” and a “beta” and a “canary” and a “stable” branch (or some greater-than-one subset of those branches) will achieve the same thing. The reason is, when there is a manual testing process, and/or an induced delay, developers will, on average, spend less time verifying their own code and building robust functional and unit tests before they commit the code in the first place. And catching bugs before they’re committed is always the best place to catch them. In other words: the necessary changes to engineering process for a “master is release” system is of significant value!