Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ship Small Diffs

blog.skyliner.io

Post reply on HN
Print view View original

31–40 of 76 posts

Re: Ship Small Diffs

#31

Post by flukus »

lolsal wrote: post #28
flukus wrote: post #27

Earlier quoted context omitted.

It's always felt like a waste of time time me, even with SVN. You always know what the released version is and can branch from there if necessary.

In larger organizations it is very easy to not have any idea what version is currently deployed. I worked for a company that cut SaaS releases every two weeks, but for various reasons the deployed version might be 1-4 months behind current repo HEAD in engineering. It got even more cumbersome deploying different versions for US vs EU and GOV environments. It's definitely not ideal, but I'd bet it happens more often t…

In everything I've worked on where we cared about the version it has been baked into the binary in an about dialog or info page somewhere, so they only way to not be able to tell which version you were using was if you didn't have access to the app.

This of course relies on having the automated builds set the version numbers properly, it breaks down if it's a manual step, which I'm all too familiar with.

Re: Ship Small Diffs

#33

Post by MaulingMonkey »

davidkellis wrote: post #10

This strikes a chord with me, but I'm coming at it from a different angle. Does anyone else encounter very large diffs as standard operating procedure in golang codebases? Here I'm considering "very large" to mean 500+ lines changed - however github computes lines changed. I mean, I'm looking at this from the perspective of someone who contributes primarily to Ruby codebases. It's understandable that there would be a…

Lots of factors here. I find it more a matter of project style/age than language.

Adding whole new chunks of code, refactoring the public interface of widely used systems, etc. tend to result in large diffs - lots of 'churn'. Extending existing code, bugfixes, more localized refactoring and doc fixes - more 'stable' codebases - tend to result in smaller diffs.

Also some difference between e.g. git and perforce - branching is easier, so I can make smaller commits without worrying about breaking the dev branch...

Re: Ship Small Diffs

#34

Post by pavel_lishin »

scott_karana wrote: post #4
pavel_lishin wrote: post #2

> You don’t need elaborate Git release rituals. Ceremony such as tagging releases gets to feel like a waste of time once you are releasing many times per day. What happens when you ship bugged code and need to roll back?

`git revert` is perfectly suited for this, since it makes a new "inverse" commit of the changes. Your production deploys continue monotonically into the future as usual, and you now have version-controlled documentation of the rollback, instead of needing to maintain a separate mapping of production code state.

Doesn't this assume you only ever deploy one commit at a time?

Re: Ship Small Diffs

#35

Post by pavel_lishin »

richardwhiuk wrote: post #26
pavel_lishin wrote: post #2

> You don’t need elaborate Git release rituals. Ceremony such as tagging releases gets to feel like a waste of time once you are releasing many times per day. What happens when you ship bugged code and need to roll back?

Just use the commit id, instead of tagging it explicitly

Doesn't that assume that you only ever have one commit per release? Otherwise, you have to keep a track of "release commits".

Re: Ship Small Diffs

#36

Post by mcfunley »

carterehsmith wrote: post #24

>> Building a web application is a young and poorly-understood activity. Sorry, no. People have been shipping, and understanding how to ship web applications for... what, 10, 15, 20 years now?

Struggling with "how long have web applications existed" doesn't help your case that they are a solved problem.

Re: Ship Small Diffs

#37

Post by farnsworth »

carterehsmith wrote: post #24

>> Building a web application is a young and poorly-understood activity. Sorry, no. People have been shipping, and understanding how to ship web applications for... what, 10, 15, 20 years now?

And how many different tech stacks have we been through in that time? I build web apps using very different tools than I used 4 years ago. I read that sentence as comparing web dev on a timeframe to, say, civil engineering.

Re: Ship Small Diffs

#38

Post by Groxx »

Ehh... nice in principle (and I do small deploys all the time for work), but too many artificially-small changes can easily cause you to "miss the forest for the trees". Each change is small and LGTM-able, but they can add up to a misbehaving system unless you have full context (which, because they're small, does not exist in the diffs).

If it's conceptually a single unit, keep it a single unit. Pushing dead code in small pieces that waits for a small master switch doesn't give you additional safety (though it can give you easier merges).

>Reviews for large diffs are closed with a single “lgtm,” or miss big-picture problems for the weeds.

That means you have bad reviews. If it can't be figured out, how was it written? Take the time and do it right. Yes, it's a large commitment - is it larger than the value being created? If no, why does it exist?

Re: Ship Small Diffs

#40

Post by carterehsmith »

mcfunley wrote: post #36
carterehsmith wrote: post #24

>> Building a web application is a young and poorly-understood activity. Sorry, no. People have been shipping, and understanding how to ship web applications for... what, 10, 15, 20 years now?

Struggling with "how long have web applications existed" doesn't help your case that they are a solved problem.

Not sure what your point is.

There is like 10 million people around that shipped a web app.

Post reply on HN