Hacker News Reader

Comment by alkonaut | Hacker News Reader

In subversion the only way I can possible develop with sanity is in an "unstable trunk". Branch off releases N weeks before shipping, and have only the requirement that trunk passes automated tests while release branches are manually tested. Obviously you don't release more than say once every month or two, but that's more than enough for most.

I'm honestly not sure if the site is satire?

No one develops in long lived feature branches in svn (rather, everyone does, but most only try it once before they realize the pain of trunk based dev is much smaller than that of svn merging).

View on HN

Not satire - If teams are doing "branch for release", they're doing it a matter of days before the release - https://trunkbaseddevelopment.com/branch-for-release/

Why wouldn't you reconfigure your CI server to also guard prospective and recent release branches??

Also - https://trunkbaseddevelopment.com/youre-doing-it-wrong/#mere...

It's not satire. In your case the automated tests are just weak. You call the trunk unstable, because you need extra manual testing. What the page describes is an improvement on that. The CI system should have good enough tests to guarantee your trunk is never considered unstable. Then it doesn't really matter when you make a release - it's not a big deal. (Just choose a commit you like)

I think "pick a commit" only holds up for server based software.

For things like large desktop software with long term supported file formats, mission critical software where people might get killed if something malfunctions etc then it's pretty normal to have manual testing. If the cost of deployment of a release is high (N people training, downloading, installing) then you want few releases - and you can also motivate spending on manual testing to ensure you don't need a new release sooner than necessary.

The release branch also works as a beta/rc branch so that a version is tested on a subset of users before general availability, while things like large refactorings and major features can start being developed for vNext in the trunk/master.

I'm not sure but I'd guess this is how most software other than web and server software is developed.

You're right. But I don't really expect anyone writing safety critical software to get their idea for the process straight off a blog. In that case you'd be going from requirements to how you achieve that. You also don't need continuous delivery. Basically a different world.

If you release only a month or 2 you are doing something really wrong (or need to work based on some insane spec). Read the basics about CI and CD, read the clean code book, read about modern organisation practices (e.g. Github releases several times a day). Releasing every month or so is (thank God) a relic of the old waterfall development times.

I would say this must be satire but you seem sincere. You are promoting a thin slice of modern "best practices" which are not the only way to do software development. And it doesn't sound like you've ever worked on a major software project if you think that a month is a prohibitively long development timeframe. A mid-size architectural refactor of a large codebase can and maybe should take a month. When you get into the 200k+ SLOC range, no one person understands the entire thing, and most of us don't want to 'move fast and break things' when a little forethought, communication, and analysis can avoid it. I think this 'growth at all costs mentality' is ruining a lot more than our software, too.

No, they're not. Is IntelliJ "doing it wrong" to release every three months[1] ? Absolutely not. A release can change things about a product, and you want to ensure you are pushing those changes (UI, behavior, plugin APIs) at a pace that matches the users. You don't want to be pushing changes to a plugin API every day. The surface area of stability that has to be maintained at that point is insane.

In the interim, you should definitely be able to build off master. Your CICD server should build and run tests on every commit to master. Then a release gets a tag in version control and you should be able to issue bug fix releases for only that specific version. Telling customers, "There is a critical security bug in version X, but in order to fix that bug you need to upgrade completely to version X+2" is not an acceptable answer.

Note that the description above works best in my experience for products that push a release artifact (like IntelliJ) versus a service like GitHub. Release management approaches will vary based on the product.

[1] https://www.jetbrains.com/idea/download/previous.html

We do CI, not CD. Lots of software doesn't do CD and lots of it can't. Games. Embedded. Desktop. Store-apps.

In my case it's large desktop software for structural engineering. Customers don't want new versions more than 1-2 times per year because of deployment, training and code compliance requirements. If we bork a release we have had users make a long download+install again. We don't just deploy the fixed one in prod to solve problems. Thats why a release goes through hundreds of hours of manual testing.

Not to mention data: a feature is a new file format. If we ship one new feature we basically ship a new format. Now you know why Autocad, Word and Illustrator ships once per year and not once per commit.

I think what a lot of people (who presumably do web dev only) forget is that web dev is just one of many software development disciplines, and a very young discipline too.

I know of the practices you mention. I like clean code (both the book and the idea). I'd do CD if I had a project some day that runs on a server. I hope I won't have to do web dev any day soon though.

You can do CD without releasing, its not pressing the release button that matters. CD means that you can press that button any time. Do small changes, test continuously, work on master.

If you make small changes and test them (using automation - unit tests, integration tests etc) you are catching bugs early, avoiding merge conflict (the most evil operation of them all). This is not my idea, its in the clean code book and its the basic of the CI/CD/TDD disciple.

And you can apply this to projects of all kind - we used it on the server, for iOS projects where we had to wait for Apple for weeks etc.

This is an important distinction. Another one is that just because you aren't deploying to production regularly doesn't mean you aren't deploying to other environments.

Reply on news.ycombinator.com