41–50 of 64 posts
With my employer we deploy several times a day. We have 2 SVN repos. One dev, one live. To make a change live you commit your change to the live repo and it is auto-synced. I am not sure how we came to have this. When I first joined there was a code reviewer who manually pushed changes live. He quit and the server admin made it auto. I wouldn't recommend this set up. I am incredibly competent. I make maybe 1 minor mi…
Live editing and debugging on the servers is strongly discouraged. But still have to do echo print_r from time to time.
Lesson learned trough the years of practice - there will always be big enough lump of fecal matter that when it hits the fan it will make you abandon all of the best practices for a while.
Nowadays it is every couple of hours. But, I used to work for departments of the UK and US governements and it wasn't unusual to have such locked-down and managed environments that it would take 6 months to release some code. It was also expensive (the sponsor department would have to pay for validation and testing by a third party). The consequence of this is that we really only deployed every 1-2 years.
When you've only got a few, experienced developers, it's much easier to ask "hey, how do you guys feel about the changes?" and push if everyone's fine. With larger teams or less experienced people, you need to go through more testing, which slows things down.
Depends on whether or not I'm actively working on a new part of the site. It varies from 10+ times to 1-2 times an hour. However, with all these people talking about deployment, I just wanna hijack (sorry!) and ask if anybody can help with my current deployment setup: - Branch into a new feature (refactor-javascript for example) - Commit constantly - Rebase with master then merge into master - Push to remote repo - S…
Have a look at Fabric ( http://docs.fabfile.org/en/1.6/ ) I wrote a quick fabfile yesterday that automatically commits/merges my local changes, pushes to a private GitHub repo, then SSHs into my production server, pulls down the latest code and restarts the web server. Gives me feedback along the way too.
Don't use fabric for deployment (even though it's a fantastic tool for many use cases).
Depends on whether or not I'm actively working on a new part of the site. It varies from 10+ times to 1-2 times an hour. However, with all these people talking about deployment, I just wanna hijack (sorry!) and ask if anybody can help with my current deployment setup: - Branch into a new feature (refactor-javascript for example) - Commit constantly - Rebase with master then merge into master - Push to remote repo - S…
This doesn't seem that bad to me, what problems is it causing? The only changes I'd make would be to wrap it up in a script so you have one-click deploys, and possibly implement the 'copy and symlink' strategy that Capistrano uses so you have minimal downtime during deploys and instant roll-backs if necessary.
Earlier quoted context omitted.
This doesn't seem that bad to me, what problems is it causing? The only changes I'd make would be to wrap it up in a script so you have one-click deploys, and possibly implement the 'copy and symlink' strategy that Capistrano uses so you have minimal downtime during deploys and instant roll-backs if necessary.
It isn't causing any problems! But in a recent thread on git deployment, there was a tonne of hate for this method
Earlier quoted context omitted.
This doesn't seem that bad to me, what problems is it causing? The only changes I'd make would be to wrap it up in a script so you have one-click deploys, and possibly implement the 'copy and symlink' strategy that Capistrano uses so you have minimal downtime during deploys and instant roll-backs if necessary.
It isn't causing any problems! But in a recent thread on git deployment, there was a tonne of hate for this method
On the staging server, I observe if everything works well by going through some use case scenarios manually. Once I'm convinced that everything works well, I deploy the new version to the production server for my beta testers to try out and give feedback.
So cycles of "new versions on production" can currently take anything between a few minutes (really quick bugfix, "OMG the website is not working at all!") and a few days (new feature)
One could complain that there should be a test suite running unit tests and integration tests, taking care of making sure everything works well. But I have two observations that make it impossible for me to rely on a big automatic test suite:
* as my website is still technically in an explorative mode, constructing test cases is wasteful: my website's architecture changes quickly to adapt to new insights. I rather spend my resources on developing features than on a test suite that doesn't work with the new architecture. * Subtle differences on my production server (limited server resources, different HTTP request behavior) make it impossible to rely on a simulated environment for my integration tests. Therefore, I have a staging server with the exact configuration as my production server. The only difference are IP address and domain name. These differences shouldn't break anything in my website, but you never know until it breaks the first time :)
Nowadays it is every couple of hours. But, I used to work for departments of the UK and US governements and it wasn't unusual to have such locked-down and managed environments that it would take 6 months to release some code. It was also expensive (the sponsor department would have to pay for validation and testing by a third party). The consequence of this is that we really only deployed every 1-2 years.
Deploying frequently when you're 1-2 developers is much easier, usually. A very important predictor of code quality that I've found is gut feeling, and, when I feel pretty confident about a piece of code, it usually turns out fine. There have been times when I said "hmm, this 3-line change doesn't feel right" and it turned out to have a bug in it, so I rely on intuition a lot (tests can't catch everything). When you'…
The end result, is that to have a patch deployed you'd have to get the patch, the whole codebase, and everything replicated and proven elsewhere (with realistica data and use cases), and a third party was contracted to do this.
It became insanely expensive to do even the smallest thing to make users or project sponsors happy... we couldn't give them code in any timely way, so everything became workarounds.
And you'd always find some project that would fight with this so much that they'd start writing in back doors. Auto-generating a WSDL on one occasion revealed a method for running arbitrary SQL. I guess some dev got sick of waiting 6 months for the next answer they needed.