Best practices in modern web projects
blog.arvidandersson.se
blog.arvidandersson.se
I think you're ascribing too much ceremony to this. It's useful to have something written down for any discussion about these changes, and a pull request is as good of a place as any for that. Plus it ensures everything is all set up to merge once you're both satisfied with the changes.
To avert chaos it's much better to have an orderly branching model in place e.g. feature branches! My fellow partners made us go all "git flow" last year and the result has been a really tidy and satisfying workflow:
http://nvie.com/posts/a-successful-git-branching-model/
Atlassian's SourceTree also helps us with maintaining "the flow":
https://www.atlassian.com/git/workflows
Git extensions and screencast on how to setup on OSX:
Similarly, hotfixes have metadata which goes to their own hotfix.csv file.
A deploy script processes the hotfixes and feature files to create a Release notes.
We've got a very smooth release documentation process which is difficult for Dev's to hate and skip.
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.
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.)
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.
The reason for trunk-based development over feature branches is that the time required to integrate a patch usually increases proportional to the square of the time since last integration. With trunk-based development, most commits reflect about 1-2 days worth of work, and they go in with minimal conflicts. Branches (and patches that sit idle for a month or two) often take forever to integrate, because as you are trying to update your code to the new master, the master is itself changing. At some point, the process doesn't converge, and you can spend forever trying to update a branch.
Perhaps this is just a terminology issue, but I strongly disagree with this. You can always merge/rebase the latest version of master into your feature branch.
...please?
However, if you have a team that is comfortable working this way -- and is only occasionally breaking things; it happens -- then it is a wonderfully creative, frictionless, and flexible way to develop.
Works well.
Break the build, all stops, and we huddle and fix it.
Sort of like the andon cord in toyota factories.
We use feature branches and issue pull requests/code reviews from those feature branches in BitBucket and it's been a universally well received tool and definitely increased the quality of our code reviews and overall code base.
If the PR method works for your team, that's great. In my experience, it leads to more friction and the reasons to implement it are usually "best practices" articles like TFA, not actual needs of the team.
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.
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.
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.
A more appropriate title could be "list of must read articles for modern web development".
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.
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...
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.
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.
But the important part is really that the deployable unit pulls its configuration from the environment where it's deployed. There are a ton of ways to accomplish this...environment variables are one way, etcd/consul is another, you can use something language-specific like JNDI or you can even use a file with configs in a well-known location, but you really need to be deploying the same artifact to QA, E2E testing, production and whatever other environments you might have.
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).
Perhaps there is something to be said for Mercurial, but unless you were previously on Subversion it's certainly not that it's easy to learn.
But who cares, because Git or Mercurial can be used in a centralized manner if you want. But it doesn't have to be. That's why it's good.
- Central repositories handle me working on a plane. Same thing.
- Central repositories handle your Chinese subsidiary being constrained to a slow and spotty pipe (they actually exported our tree with git-svn and used git on their end--this was at a NASDAQ company, it's not like anyone was cheaping out, it was the best available).
That you are willing to work around the deficiencies of centralization does not mean they are not deficient. Don't be ridiculous.
They're not the 90% case, anyway, almost by definition. =)
Also, many of Git's most powerful features have nothing to do with being distributed. Easy branching and merging, private versioning, bisect, rewritable changesets, stash, and the ability to cherry-pick individual changes within a file to commit, back out or stash could all theoretically be built into a centralised system.
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.
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?
Also, another website I administer has a lot of user uploaded content that's constantly changing. I've not dealt with a CDN before, so I don't know how CDN helps with that? I think only a fraction of the data is static in this case.
PS Why the hell would someone downmod my honest question?
In addition, with mobile, getting rid of any network latency you can is going to help.
In general, though, I think you are right to ask the fundamental question. That said, it's something a lot of people end up needing anyway and it helps if you design for it up front.
tl;dr - If you're building a low-volume site, the OP probably doesn't apply to you.
I think having CDN as a basic requirement for all projects is... ill-considered. Remember, using a CDN is giving away data about your users' browsing practices without their consent.
But like anything, it depends on the use case. If the product is primarily a file server like Dropbox then maybe using a CDN early makes sense. Or your smallish number of users are spread across the world might be another use case.
But most importantly, it lends to dynamic configuration when using etcd or zookeeper.
Not to mention those points were mainly subjective. Don't get me wrong, I like and use Git myself but statements like "Use this, most people use it so you must use it too!" are just horrible.
Because the basics have to be pointed out again ... and again.
I think the upvotes don't primarily mean "omg I never thought to do this" but rather "will someone please staple this to the foreheads of all the clueless devs I've had to clean up after."
Yeah, that's sort of what "best practices" are all about. They are for teaching outsiders what insiders have learned through practice. The intended audience is everyone who doesn't already know this.
If you consider the article of no practical interest for a seasoned insider, that's about the highest praise you can give.