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

Best practices in modern web projects

blog.arvidandersson.se

Post reply on HN
Print view View original

81–89 of 89 posts

Re: Best practices in modern web projects

#81

Post by buffportion »

joshuacc wrote: post #79
buffportion wrote: post #62

Earlier quoted context omitted.

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.

> If you are using branches you really aren't doing CI, because you aren't integrating continuously. 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 .

That will integrate other people's changes into your branch. But until you also merge your branch into master (and/or all other branches), you are not integrating your changes.

Re: Best practices in modern web projects

#82

Post by nostrademons »

IgorPartola wrote: post #69
buffportion wrote: post #62

Earlier quoted context omitted.

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.

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…

Both Google and Facebook use trunk-based development. If Google can get away with a single trunk and 15,000 or so committers, chances are your organization can too.

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.

Re: Best practices in modern web projects

#83

Post by [deleted] »

jaegerpicker wrote: post #53
IgorPartola wrote: post #34

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.

I couldn't disagree with this more. Pull requests provide a quick and relatively pain less code review tool. Unless you are suggesting that code review is a bad practice, which in that case I'm pretty well dumb founded as I think it's a requirement for intelligent modern development.

[deleted]

Re: Best practices in modern web projects

#84

Post by gnaritas »

eropple wrote: post #80
gnaritas wrote: post #76

Earlier quoted context omitted.

Those things don't require distributed source control; they simply require remote access. Substantiation simply isn't necessary, you haven't given scenarios that demand distribution and you can't, because honestly there aren't any. Distributed source control is a preference, a style, not a necessity. Central repositories with remote access handle all of those use cases. Other than perhaps the Linux kernel, there's ve…

- Central repositories handle me working from a coffee shop with spotty wi-fi. No , I am not going to wait to commit until I get home, because I want a set of commits as I go so I can revert if I screw up. - 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 u…

My bad, I was overly huperbolic; of course there are situations situations in which distributed is clearly better. I use git. But I'd say those easily fall in the small minority of situations. Most of the time for most programmers I think, internet access is not an issue.

Re: Best practices in modern web projects

#85

Post by eropple »

gnaritas wrote: post #84
eropple wrote: post #80

Earlier quoted context omitted.

- Central repositories handle me working from a coffee shop with spotty wi-fi. No , I am not going to wait to commit until I get home, because I want a set of commits as I go so I can revert if I screw up. - 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 u…

My bad, I was overly huperbolic; of course there are situations situations in which distributed is clearly better. I use git. But I'd say those easily fall in the small minority of situations. Most of the time for most programmers I think, internet access is not an issue.

No worries. But I'd turn that around: is it not an issue because it's not an issue, or is it not an issue because we are trained to alleviate it? 'Cause I enjoy working from the park, too, and I wouldn't even want to trust tethered 4G to not be a pain in my ass while doing it.

Re: Best practices in modern web projects

#86

Post by curun1r »

kylequest wrote: post #41

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…

I think they made a mistake by making the "gets configuration parameters from the environment" specific to a UNIX/system environment. You can accomplish the same effect in a much more elegant manner using a tool like etcd or consul.

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.

Re: Best practices in modern web projects

#87

Post by xtracto »

hoggle wrote: post #49
IgorPartola wrote: post #34

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.

We are a trusting team and don't do pull requests with our closed source repos either. 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 work flow : http://nvie.com/posts/a-successful-git-branching-model/ Atlassian's SourceTree also helps us with maintaining "the…

We have been using Git Flow in our team too. One advantage I se is that using git-flow specific hooks we add some metadata to every time a feature/ branch is finished. This metadata goes into an automatic Release notes file which is automatically added to the repo (as an amend of the flow's last commit).

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.

Re: Best practices in modern web projects

#88

Post by gnaritas »

eropple wrote: post #85
gnaritas wrote: post #84

Earlier quoted context omitted.

My bad, I was overly huperbolic; of course there are situations situations in which distributed is clearly better. I use git. But I'd say those easily fall in the small minority of situations. Most of the time for most programmers I think, internet access is not an issue.

No worries. But I'd turn that around: is it not an issue because it's not an issue, or is it not an issue because we are trained to alleviate it? 'Cause I enjoy working from the park, too, and I wouldn't even want to trust tethered 4G to not be a pain in my ass while doing it.

The park... me thinks you live in a bubble and don't know what the average developer day is; believe it or not, most developers don't use git or any kind of distributed source control because most developers aren't working for cool startup's in the valley or on open source projects. Most developers are banging out Java and .Net apps for corporations using some form of centralized version control and not being able to work from 4G in the park isn't a problem they ever face.

Re: Best practices in modern web projects

#89

Post by eropple »

gnaritas wrote: post #88
eropple wrote: post #85

Earlier quoted context omitted.

No worries. But I'd turn that around: is it not an issue because it's not an issue, or is it not an issue because we are trained to alleviate it? 'Cause I enjoy working from the park, too, and I wouldn't even want to trust tethered 4G to not be a pain in my ass while doing it.

The park... me thinks you live in a bubble and don't know what the average developer day is; believe it or not, most developers don't use git or any kind of distributed source control because most developers aren't working for cool startup's in the valley or on open source projects. Most developers are banging out Java and .Net apps for corporations using some form of centralized version control and not being able to…

Sure. But worrying about the average developer doesn't do much.

They're not the 90% case, anyway, almost by definition. =)

Post reply on HN