Hacker News new | ask | show | jobs
by mkl95 387 days ago
> less manual work is always better.

Why do your releases involve non negligible manual work?

> We release 1-3 times per week.

If I were a customer, I would be concerned by this statement. Having an amateurish deployment strategy is one thing, but your release cadence implies low confidence and quality issues.

2 comments

The cadence of releases is not related to quality. There will always be variances depending on the codebase involved and organisational constraints and product velocities. I could easily say that more frequent or less frequent releases are also a cause for concern.
We are talking about a Gen AI startup that has a handful of employees here. They have little excuse not to implement CI/CD, unless they lack confidence in their product's quality.
Ignoring the Claude AI release, why does releasing 1 - 3 per week implies low confidence and quality issues?
It means you release whatever you have first thing and then release a bunch of patch releases on top as the QA (outsourced on users, probably) results come back.

Sans security patches, why are your features not sized to roughly a sprint? What do you manage to prepare, build and validate in a day or two? To me release cadence less than every few weeks screams "whatever landed in master is good to go" and is a sign of mis-/un-managed development.

Maybe they don't do sprints.

Yeah, could be user feedback. And if it's a public beta release why not?

3 devs working for 5 days on each their feature means 3 releases per week.

For the last 10+ years I have been working on the same project with 2 releases per year, so what do I know. But I have used projects with quick release cycles that work very closely with the community. Push new beta, feedback on discord. Was also fine from my (limited) perspective.

Because they should be spending one day writing scripts and github actions for their CI/CD system before pushing out new code by hand or AI assistance several times a week.

Releasing 1 - 3 times a week means it's 1 - 3 times more important to have a deterministic release process than if you release 1 time a week.

Yes yes, I agree with a deterministic release process. I get that, and it's not what I'm asking about.

I still don't understand why 1 - 3 releases per week implies low confidence and quality issues.

> but your release cadence implies low confidence and quality issues.

curious why would it imply that.

Why would a startup CTO choose to deploy a couple of times a week with a Claude script instead of implementing basic CI/CD? He makes it sound like he's running a clusterfuck and he isn't qualified for the job.
Aren't you assuming a bit much here? They have implemented CI/CD; their Claude script triggers the git branch part of the release flow, which is what in turn triggers the CI/CD pipeline—a completely normal thing to do, even in established teams (save for the Claude part).

The guy automated the toil away using AI. Not that I would feel confident automating away that part in particular, but it does neither speak badly of the code quality, nor his job qualifications.

Because there is more toil in writing a blog post about how you use AI to do a release, than there is in writing a script that makes the AI and the blog post unnecessary.

But then you wouldn't have something about using AI to blog about.

That’s an entirely different issue: people maintain a blog to improve their hireability, and that entails blogging about things that may not always be brilliant insights. It’s not this person's fault that that’s the state of tech hiring however. Don’t hate the player, hate the game.
Blogging is actually a good way for professionals to earn CEUs to maintain certifications.

Chances are, if you’re reading low-effort blog posts that are consistently in certain knowledge domains, they’re intending to apply for CEUs at renewal time.

It really depends on the product. Especially if 0-downtime deployment is not possible.
why not have CI?
But the questions was about the cadence and not the method.