Hacker News Reader

Comment by majewsky | Hacker News Reader

"Ship daily" only works with web applications. If I were to ship my applications daily (or rather: each day where there occur changes), I would just be compiling packages all the time. (Before you ask: This cannot be automated further. I will not give my GPG key to some automation to sign the packages with.)

View on HN

I automate my deploy process by passing my password as an argument to my automation script. maybe you can try figuring something similar out.

Because yeah, by hand, even deploying my webapp would take a couple hours. it took me maybe 8hrs of labor to setup my deploy script but given as I've deployed maybe 50 times so far it's paid off.

Hours? Could you elaborate a bit what exactly you mean with "by hand"? I'm probably not thinking manually enough, I can't come up with what could possibly that time intensive about any deployment.

"By Hand" I mean running each command required to deploy line-by-line, at the command line.

For me, that would be:

1) provision VM

2) configure the new VM (security hardening, install utils)

3) download app from git and configure it

4) take image of vm

5) install new image into my autoscaler

6) hot-replace live instances of previous version with new version.

doing each of those commands by hand and waiting for each to complete could easily take 1.5 or 2 hours of work. I did it by hand the first couple times but once I figured out my workflow I automated it (bash script) as fast as possible.

I spent a couple days looking into ansible, but as I have a very specific need I didn't want to spend 2+ weeks adding another chunk of "technical debt" to my product.

I already have a Makefile to automate most of the steps, but you still need to write changelogs, push a signed tag to Github, update the package specs and create and push all the repos.

Surely you can give it to another box in your house that tries to build on commit all day?

You can ship daily even if your process is not automated. I usually automate building and deployment later in an application's life -- not at the beginning.

You can automate all steps for building an application but the signing to make your life easier. You can also automate things locally if you're worried about what you're signing.

The bottom line is that this applies to all apps (though your users might be irritated if they need to keep downloading updates).

But trying to automate everything is why I never get shit done.

I think the basic idea is get it running and keep it running making incremental improvements. Whether your project is in an interpreted language or takes a day to build only changes the pace. I've worked on both time scales and focusing on getting something basic running then adding to it has worked for me.

Well to be fair, this is mostly what we're all discussing on here. Web Applications.

Any advice for non-web applications? Building a library, desktop application, and soon.

ship weekly!

When I was working on a game, we created a Patreon and promised new demo to backers every month. It's very motivating - you have clear deadline, money and feedback.

Web apps have the advantage that users don't have to actively update anything. One page load and they use the updated product.

Receiving daily updates for desktop apps would suck because it typically requires the app to quit and start again. A good compromise would be updates every four weeks. At the same time you as a developer always leave your app in a state were you could push an update anytime. So you still work incrementally in daily units of work.

Daily updates for libraries … if it's only publicly available code, I don't see a reason not to push daily. Anyone interested can check the commit logs. For compiled binaries on the other hand I can see update fatigue for users (other developers). Once a month or longer seems fine.

In the end, push regularly (daily, weekly, monthly, whatever fits you) without annoying your users by spamming them with updates, while at the same time reduce work units to a size that does not feel overwhelming.

You could have a "nightly" release, which is updated as often as you like, alongside the "real" versions. Those who want the nightly can have it, those who want steady, stable releases can avoid it.

Push to your own local repo daily. Push to the actual users less frequently. Weekly, monthly, 3 months, just pick something reasonable and -stick to it-.

We have a desktop app and build several times a week sometimes.

Reply on news.ycombinator.com