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

61–70 of 76 posts

Re: Ship Small Diffs

#61

Post by seanwilson »

iamleppert wrote: post #60

This is nonsense. The number of lines of change of code has absolutely nothing to do with the amount of risk. A single line change can easily break an entire system. Applying this size fallacy, however is just as dangerous. Certain classes of changes should be grouped together so they can be reviewed with the context required. I've had the unfortunate task of working in environments where I've been forced to artifici…

> Certain classes of changes should be grouped together so they can be reviewed with the context required.

Agree with this. I've worked in teams before where the order of tasks to be done was chosen by someone not on the development team and I found it seriously inefficient. When you're reviewing code, you have to think "what could this break?". When you group related changes together the surface area of things that can break is lower so you can more efficiently check for issues.

Re: Ship Small Diffs

#62

Post by _ph_ »

Groxx wrote: post #38

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…

I read such articles more like a general guideline than a strict requirement. Of course it is bad to split up commits, which are one unit, into several parts. But when in doubt, you should try to commit in smaller batches. And by all means try not to commit unrelated changes in one commit.

Re: Ship Small Diffs

#63

Post by alkonaut »

Groxx wrote: post #38

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…

Review of 10 lines: 10 issues. Review 1000 lines: LGTM. As the article says - even the best strongest teams and culture will fall in that trap.

Avoiding review fatigue has to be done some other way than merging smaller diffs, for example splitting changesets among reviewers so that person A reviews the backend code and person B reviews the frontend code etc. A meaningful feature of 1000 lines can still be reviewed in terms of 20 50-line changes, and doesn't have to be reviewed in one sitting or by one person.

You are perfectly right that pushing dead code and half baked features (that won't be used, so aren't actually in production!) is useless and adds no safety. Adding a new feature is risky, and adding it as 99% dead code and then finally adding the 1% code with the button that actually enables the feature in the UI doesn't help - 100% of the new code will hit production with that final change.

Re: Ship Small Diffs

#64

Post by yason »

Paraphrasing "as simple as possible but no simpler than that": ship as small diffs as you can but no smaller than that which makes sense.

Individual commits don't necessarily make sense in the whole. Submit diffs which make up a logical, conceptual block of new changes. Don't mix formatting changes, whitespace cleanups, or rearranging changes into diffs with real meat. Ship new prerequisite tools and new changes to utility functions or libraries first, then the meat: i.e. split general codebase upgrades and distinct features into different shipments.

Make it so that "git log" will produce a list of sensible steps if someone else reads the listing. Remember, 90% of programming is writing good code and the other 90% of programming is communication to others.

Re: Ship Small Diffs

#65

Post by byroot »

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.

Having an actual rollback mechanism that brings you back to a known working version is usually way faster than pushing a new version, since it needs to go through CI / Build etc again.

At my company rolling back is a matter of a minute or 2, while pushing a revert is more in the 5 to 10 minutes. Your mileage can definitely vary though.

However it requires all the shipped changes to be rollback compatible, which isn't that hard with a bit of experience.

Re: Ship Small Diffs

#66

Post by byroot »

pavel_lishin wrote: post #35
richardwhiuk wrote: post #26

Earlier quoted context omitted.

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".

It's better to have an activity log of your deployments, that way by querying what commit is currently in production you can compare it with the log and know what actually commit range was deployed.

There is many tools to do that, e.g.

  - Shopify's Shipit: https://github.com/shopify/shipit-engine (author here)
  - Zendesk's Samson: https://github.com/zendesk/samson
  -  Netflix's Spinnaker: http://techblog.netflix.com/2015/11/global-continuous-delivery-with.html
  - Yahoo's Screwdriver: https://yahooeng.tumblr.com/post/155765242061/open-sourcing-screwdriver-yahoos-continuous
  - Instagram's Sauron: https://engineering.instagram.com/continuous-deployment-at-instagram-1e18548f01d1#.tv6zycskx
And the list goes on.

Re: Ship Small Diffs

#67

Post by Vendan »

Groxx wrote: post #58
Vendan wrote: post #17

Earlier quoted context omitted.

I think you have those backwards. Concise is expressing an idea in less words, expressiveness is the breadth of ideas that can be communicated. Go is not concise and does not try to be.

Just to play devil's advocate (in case this is what they were thinking), go's language definition is fairly concise, by design. Few keywords, little magic, leading to lower expressiveness per LoC.

When talking about lines of code written, "concise" is roughly "idea/length" whereas "expressiveness" is "sum of ideas", so yes, "concise" could be roughly seen as "expressiveness / LoC", but it's still the wrong word to use, as "expressiveness" specifically refers to the "breadth of ideas that can be represented and communicated". And either way, while the language spec is concise, the language itself is most definitely not

Re: Ship Small Diffs

#68

Post by tcoff91 »

mden wrote: post #16

This is something I've had a lot of problems with. I understand the benefit of small diffs, but I can't seem to find a way to really apply this for any actually meaningful changes. In my experience I would spend some time coming up with a system of multiple abstractions that are interdependent and then getting single logical commit for proof of concept would require hundreds of lines. Splitting the abstractions into…

I have had the same experience. I work on a number of large C++ codebases at work and often times I just can't find a way to break most things up into small diffs.

Re: Ship Small Diffs

#69

Post by nradov »

hyperpape wrote: post #50
nradov wrote: post #41

Earlier quoted context omitted.

I work in an enterprise Java setting but I don't believe that this is a language specific issue. Our diff sizes vary by 3 orders of magnitude, so it would be meaningless to give an "average" line count. Each one is just large enough for a complete user story or defect fix, no more and no less. User stories have to be defined and broken down based on business value delivered to the customer regardless of how large or…

I'm in the same boat, but I feel like the problem is tying the commits to the user stories. Ideally you'd be able to make multiple commits to implement a single user story where it can't be done with a small amount of code.

Sure there are multiple commits on a branch, but when we merge back to the trunk the whole user story has to go in one shot. We can't put a partial user story on the trunk because then it wouldn't be in a fit state to release.

Re: Ship Small Diffs

#70

Post by carterehsmith »

mcfunley wrote: post #46
carterehsmith wrote: post #40

Earlier quoted context omitted.

Not sure what your point is. There is like 10 million people around that shipped a web app.

Ok, I'll give you a serious answer. For an individual shipping a website, anything at all works. I'd guess that half of all websites that have existed are just a single person editing files directly on a webserver without source control, and that's fine. It's another matter altogether to ship code with tens of thousands of requests per second and a lot of teammates trying to change it simultaneously.

>> ship code with tens of thousands of requests per second

Define "request"

If the "request" is to deliver some static file, that has been solved many years ago with CDNs and server caches and so on.

If the "request" is to do something other than static files, it has nothing to do with Web. It could be request to your bank's COBOL app or a request to their Java app or to their Node.js app. Nothing to do with Web.

Post reply on HN