
Best practices in modern web projects - arvida
http://blog.arvidandersson.se/2014/06/17/best-practices-in-modern-web-projects
======
IgorPartola
Ugh. Pull requests again? OK, look, unless your team is so large that you
can't effectively communicate otherwise, pull requests are just friction. Use
feature branches, then merge them when they are ready. Trying to pretend like
your two person team is a huge open source project with many distributed part-
time and full-time developers is cargo cult at its worst.

~~~
buffportion
Or don't use branches at all. Develop on trunk/master with continuous
integration. It reduces work-in-progress, exposes conflicts sooner and has a
host of other knock-on benefits.

~~~
chrisweekly
To 'CI' [per se] I say "yes, of course." It's a best practice. But it is not a
substitute for branching! I want to choose when I'm exposed to conflicts.
"Sooner" is usually -- but not always -- "better". Summary: strong
disagreement on this radical approach.

~~~
buffportion
I don't consider not-branching to be a radical approach. If you are using
branches you really aren't doing CI, because you aren't integrating
continuously.

~~~
IgorPartola
So there are projects where I don't branch: ones where I am the only
committer, and there are no features. For example, my puppet manifests for all
the servers I manage. It either works, or I roll it back.

However, feature branches are just multi-stage commits. Sure you can invest
hours of your life setting up CI, then writing code, not testing it locally
before pushing it to master, getting an obscure error from the test/deploy
process, fixing it again, pushing again, getting another error, etc. But you
probably want to, you know, ship the product.

Having said that, if your workflow actually resulted in you writing better
code faster and you ended up shipping earlier and making more money, I'd love
to read about it.

~~~
buffportion
"Sure you can invest hours of your life setting up CI, then writing code, not
testing it locally[...]"

Maybe I've misunderstood, but why aren't you testing it locally? With trunk
based development you make your changes, run a local build and push if it
passes. Everyone (including any CI servers) runs the same build process.

The trick is that you have to be able to push to master without breaking it,
which is scary to many developers and usually requires a shift in thinking.
How do I do large refactorings? (you don't - do many small refactorings
instead). How do I add a half-finished feature? (break the feature into many
smaller features, use feature toggles, etc.)

~~~
IgorPartola
Of course. And this relies on your CI system having 100% unit and system test
coverage, including testing external API's, CSS bugs, browser compatibility,
etc. Are you certain that your system does that? More importantly, are you
certain that investing the time into testing that your checkout button is not
covered up by some random element due to a missing ";" character in your CSS
file or a missing 0 in the width percentage value will eventually pay off? It
should be scary to push to master if you hold master to be deployable at all
times. Unit/system testing or not, you will never have guaranteed test
coverage, and even if you try to get to it, you will spend infinitely more
time doing that, than doing a reasonable amount of unit/system automated
testing + good human QA.

~~~
buffportion
That's really a function of your QA process, not anything specific to
branching strategies. If you can automate everything such that continuous
delivery (or even deployment) is possible - great. If not, deliver at whatever
pace your QA allows (and strive to increase that pace). Trunk based
development does not imply a diminished QA process.

Yes, there is always going to be a feedback delay between you making a change
and the full impact of that change being known (even if your feature is bug
free, will the customer want to use it?), but we should be bringing that
feedback forward by moving changes through the pipeline as early as possible.
Feature branching delays feedback, which is why I reject it.

------
Nexialist
The "12 Factor App" manifesto [http://12factor.net/](http://12factor.net/) is
in the same vein as this, perhaps a bit more in-depth.

I like the idea of these guides generally. I think it'd be more valuable if
they linked to example production code that followed the principles however,
since there's no substitute for the real thing.

Come to think of it, I've never seen anybody write up any kind of index of
(for example) Github projects that exemplify good design patterns for people
to look at. Or some kind of recommended code reference list.

~~~
pmichaud
I like that idea too, but I suspect that there are pretty much zero non-
trivial projects that actually follow best practices like these consistently.
Maybe I'm wrong.

------
owenversteeg
I disagree with "Keep the master branch deployable at all times." Both my CSS
framework Min ([http://minfwk.com](http://minfwk.com)) and several other
popular GitHub projects use the strategy of 'only use one branch, and use tags
to mark stable versions'.

Min's only branch (gh-pages, so we can serve the site with GitHub) is usually
"unstable" (in the sense that a CSS framework can be unstable.) If someone
wants a stable release, that's what Git's tag system is for.

~~~
awj
I think the idea is sound, but the reasoning isn't. Keeping master deployable
at all times forces breaking changes off into feature branches so unrelated
pieces of functionality can't interfere with each other's release schedules.

Keeping master deployable for bug fixes doesn't make sense to me, though. Are
you going to deploy new features sitting in master because something else had
a bug? Just go look up the last release tag, make your bug fixes there, then
merge them into master.

I've been bitten too many times by unstable features holding up releases on
master (both my features and other team member's). Feature branches do a
wonderful job of solving this and the required merge back into master gives
you a nudge to prevent scope creep.

------
parham
These aren't really best practices, they're too abstract. Best practices would
be exactly how you do said practices the best way possible.

A more appropriate title could be "list of must read articles for modern web
development".

~~~
csbrooks
I'm not sure about that; I feel like I got a lot from the article without
following the links.

~~~
parham
This didn't cover anything useful it just said what everyone was already aware
of, the only useful part was the links. Everything else was like saying to
spread butter on toast use a butter knife.

~~~
Lockyy
>just said what everyone was already aware of

What you mean is it just said what you were already aware of.

Not everyone does know all of these things, a list of things with generalised
statements along with links to more detailed information is incredibly useful
to someone who is just getting into the field, which I guess is exactly who
this article is aimed at.

------
kylequest
I wouldn't call the part about configurations (in the post and in the 12
factor app reference) a best practice. Using environment variables is a hack
that has negative side effects including security side effects.

This statement is just silly: "A good goal is that the application can be open
sourced at any time without compromising any credentials." It's silly because
the use of environment variables doesn't prevent anybody from putting them in
a shell script that gets committed to git...

~~~
njharman
You're reversing the "goal" and "practice". It's not that Environment Vars
allow you to "open source / credentials".

It's (goal) "be able to open source any time without compromising any
credentials". One method (practice), use Environment Vars. Evars being a poor
choice in your and somewhat my opinion, does not translate into the goal being
poor. It's a laudable goal.

~~~
kylequest
Being able to open source code without compromising any credentials is a great
goal, but using environment variables doesn't really accomplish it UNLESS your
code only runs on a PaaS, which will always supply all of your app's env vars,
but it's unrealistic for a number of reasons.

First, there'll be extra vars that your PaaS won't fully manage, so you'll
have to keep track of them yourself and then later configure the PaaS
environment, so your app can access them. Second, for non-PaaS
applications/deployments you still need to manage the environment variables.

The variables don't magically appear by themselves :-) They need to be stored
somewhere... This "somewhere" is likely to be the git repo (for the app), so
you are back to square one on this.

------
st3fan
I am sad that this article does not contain the word 'Security'.

------
collyw
"Git

First of all, use git for version control. It is modern, works great and the
majority of developers are either comfortable in using it or want to start
using it.

Its a pain in the arse to learn, overcomplicated for 90% of the cases it is
used in. How many people actually need a _distributed_ version control."

(I use Git. It is powerful and useful, but the justification for using it in
the article isn't really great. No mention of Mercurial or other version
control systems).

~~~
Expez
The benefit of standardizing on a tool that is "good enough" is worth it imo.
Learning git is easier than learning svn, darcs, hg, perforce and git and
juggling between them when you want to submit patches to open source projects
or get new clients.

~~~
collyw
I am not going to argue with you on that point, because that is the reason I
am using GIT. CVS would be far more suited to my personal use cases.

~~~
eropple
I'm curious how CVS is suited enough to _anyone 's_ use cases to be worth
discussing when SVN exists.

------
ericcholis
All of this really covers the primary thing I preach when working with new
devs. "You shouldn't be the only one who knows how to set this up and run it."

One thing that might be missing is good code documentation. Using DocBlock for
PHP, for example. Ideally this is maintained in code, but that can get bloaty.
At the very least, a git repo of markdown files. Even the built-in github
wikis would suffice.

------
Demiurge
>Serve these through a CDN that is optimised for serving static files to
ensure high transfer speeds and therefore increased user happiness.

I was not aware this was that common or even considered always the best
practice. Is this really the best practice for any website? How exactly is a
CDN more optimized than nginx on a dedicated server with 1GB connection?

~~~
ape4
Is there an entry level CDN. Enter your credit card and get access, upload
files and go. For a few bucks a month.

~~~
numbsafari
Look at CloudFront from AWS. CloudFiles from Rackspace used to also include
built-in (no additional charge) distribution over Akamai as well, though it
had limitations on the number of purges you could do, I think.

------
Arkadir
Honest question: what are the benefits of using environment variables over
having an actual configuration file (that is obviously not added to version
control) ?

~~~
IgorPartola
Unless your environment demands it, it doesn't matter. In fact, it can be a
bit of a pain in the ass to implement on your own, if you are not using Heroku
or some such. The main point there is to not put secrets into your git repo.
How you accomplish that for the most part doesn't matter.

------
AlexMuir
No idea how this is getting so many points. There's absolutely nothing of any
practical interest here. Use version control and documentation... End of post.
I'd say these are more industry standard practices than leading edge.

~~~
joshdotsmith
There will always be a new freshman class. Every year, someone joins HN (or
the community at large) knowing next to nothing. We should welcome those
people, not make them feel bad for being new.

~~~
noblethrasher
Yep. HN wants to avoid _eternal_ Septembers; occasional Septembers are fine
though.

