339 karma · joined June 14, 2011
I've worked on sites before where if you logged in as the admin it started attaching a header with the ip of the application server responsible for generating that page to help with debugging. It's not outside the realms of possibility that something like that could break and start leaking ips.
I can see that you could potentially form a similar explanation around that scenario too but it doesn't seem as convincing.
ssh -x example.com
cat /var/log/syslog | grep event | xclip -i
Your X clipboard will be shared with the host so the output will be placed into your local clipboard.Using Capistrano, for (1) I can just mark a target server as the update server to run these commands. With packages, I assume I either have to have a different version of the package or rely on some sort of environmental variable which the package reacts to?
2) Yep that would be slightly ridiculous for production, but I was thinking more along the lines of UAT, staging and other shared testing/development environments. It's not ideal but I have been in the situation where this was required.
3) True, but with Cap I can just issue a rollback and it will revert to a database snapshot that was taken from the last version. I can't see how we could do something like this with packages alone.
Maybe you mean that these problems are outside the scope of packages and that I should be using packages with something like capistrano to solve them but then why wouldn't I just use Capistrano on its own?
1) Clusters of application servers, where I will only want operations on shared resources to fire from one of the servers? E.g. database updates, shared file changes, etc.
2) When I want to deploy the code to a different location on the server so that I can have multiple versions of the application available? Do I have to spin up new servers for each version?
3) You mention roll back by just specifying an earlier package but I don't see how this would work with stuff like database changes either.
As far as I know there's no SCM system which can understand the /intent/ of the change and without being able to reconcile the intents of two conflicting merges there's no way of reliably merging the code (at least as far as I know).
My guess is that trunk based development is the idea that all commits pushed to the canonical repository are pushed to trunk (rather than a remote branch) with incomplete code being hidden using feature toggles?
In contrast mainline would push incomplete code to long lived remote feature branches and those branches would only be reintegrated into trunk once the code was complete.
However, I don't really see how this relates to a lot of the rest of the article which seems to be more to do with versioning, dependency management, and testing.
There's also some more specific points I'd like to pick up on:
Is it really easier to rebase my local branch than it is to merge from one remote branch to another? Seems like half a dozen of one and six of the other to me.
The article contrasts Google's & Facebook's model with the pull-request model of Etsy and Github but again I don't really see much of a difference. Facebook sends a patch to phabricator for review, someone looks over it and then it gets committed to trunk.
P = 1 - \sum_{m=0}^K \choose{m}{K} (1-beta)^m (1-alpha)^m alpha^{K-m}