Ask HN: What does the ideal deployment process look like for this scenario?

7 pointsby ninjaaalmost 17 years ago

Our team of two developers has taken on a new project: updating a slightly rusty PHP 4.x/MySQL 4.x e-commerce solution with a stable but small (< 50) customer base. The lead developer left recently, we have just jumped on board to modernize the project, which suffers from age - it's entirely procedural, not even one AJAX call, ugly UI, some huge tables, barely any caching and scattered ugly joins etc. But it suffers from no major architectural defects and generally works very well. We've been able to successfully integrate it with outside APIs.The project is going to be worked on by three programmers. The storefronts, UI elements and templates are to be worked on by two web designers. We two developers are currently on-site, and the third is off-site (in a foreign country). We've been working for a while, but the off-site person rolls on next week. The designers have also just begun working on new storefronts.The old dev server got kind of crusty - it had fallen out of sync with the live, and some functionality was lacking. For example, it was previously impossible to host development storefronts locally. In-house we took the trouble to set up a fresh dev server with dev storefronts and local DNS. Finally, we don't really have any testing yet, although of course we plan to introduce some in the medium term (2-3 months).After a few weeks of work on this project we're about to jump into the plumbing, i.e. update versions of PHP and MySQL, optimize queries and perhaps add a class structure (Previously we were polishing the UI and performing minor optimizations and API integration).Suddenly the quality of our dev setup and live deployment process has become very important. There are a decent number of businesses that depend entirely on our product for inventory and e-commerce. Unscheduled downtime of more than a couple minutes is unacceptable any time. We accidentally took down the live server for 15 minutes one afternoon last week and were deluged with phone calls from business owners.Currently we've not yet installed version control. Typically this is the time to introduce Subversion, or perhaps even Mercurial (used it before, a good improvement over SVN but interface was clumsy and merging seemed to be a kludge still) or Git.I invite HN commentors (commentators?) to advise us on what a decent development setup and deployment process is in this scenario. Nothing too complex or rigid obviously. For the moment it can remain a little sloppy. It's too early to tighten it up into something formal. We need to transition into it.Also, intellectually I prefer DVCS, but is it overkill for this scenario? Especially given that the off-site person may have no exposure to the concept, and that it will take a while for our web designers to get it as well. We can after all, introduce it in the future with minimum hassle. We're working at a pretty brisk pace, I don't really want to slow everybody down at this time by introducing a confusing, command line VCS. Also, in our office we have a couple PCs, a couple Macs and a couple linux boxen. Everybody works across platforms. How do we put a system in place that gives us freedom to develop quickly, can ensure a reasonable (say weekly) sync with the live server on a regular basis, and at the same time maintain easily deployable backups?Free thinking is welcome, but experience in similar situations is what I'm looking for. Useful links from YC (I searched on searchYC first) or anywhere on the internet are also welcome. I look forward to reading your opinions.PS We have budget and so will definitely at least consider proprietary systems or managed VCS if they come well recommended and reasonably priced.

6 comments

mechanical_fishalmost 17 years ago

It doesn't matter which DVCS you use, particularly since you haven't mentioned using CVS (thank god). Use whatever the designers will actually use. If they're already comfortable with SVN use SVN; the git-svn integration tools are not as great as an all-git setup, but I've been using them with great happiness. And there are quite a few competing GUI clients for SVN.Pay Devguard or github or somebody to host your VCS. Don't waste your client's money setting it up yourself.Given this sentence:Unscheduled downtime of more than a couple minutes is unacceptable any time.My first instinct would be to try and get the production server mirrored to a nigh-identical second box that you can, in a pinch, fail over to. Once you know how to do that you can clone one or the other of these redundant production servers to a staging server and test your new code on that.For all of those tasks you use boxes that resemble your production box -- same Unix version, PHP4, MySQL 4. Slicehost VPS instances are cheap. Rental servers are cheap. But trying to get your motley collection of Macs and PCs to accurately simulate your deployment environment may cost a lot of time.You can use your local machines for development if you want, then upload the results to the staging server for testing, but even that might be a big time sink, depending on the nature of your app. I've been working that way, but I've now been bitten more than once by bugs that are caused by slight differences in versions or modules between my Mac's PHP/MySQL setup and that on the production servers. I've begun to wonder whether it might be better to just get each developer a remote development VPS (or a directory on a shared development VPS), install identical clones of the development code and the database for each developer, and have everyone develop over a SSH connection, and/or via an intelligent sFTP client like Transmit for the Mac. This, I'm told, is how Flickr develops new code -- their production environment has too many moving parts to be worth simulating on a single local machine. But, of course, I'm an emacs user so the thought of editing files over SSH isn't that horrifying.If you're going to be tinkering with mission-critical code that costs $N per minute every time you introduce a bug, you may need to move the writing of tests up in the calendar.Don't forget the bug tracking! I'm not in love with Trac but it gets the job done -- again, pay somebody like Devguard to host it for you; don't waste time setting it up yourself. Or try Lighthouse or something else if you don't like Trac. Try out Basecamp.

评论 #297060 未加载

davidwalmost 17 years ago

> slightly rusty PHP 4.x/MySQL 4.xMy first instinct is "take off and nuke it from orbit, it's the only way to be sure", but in all seriousness, it's a pretty good question, as lots of people have to deal with fixing up code like this instead of just doing some big rewrite with tools that are nicer.If you're not familiar with how Rails (and Django?) do things in terms of having devel, test, and production environments, those would be a good thing to have a look at in terms of a model to copy.Try and aim for this: production server, staging server that very closely mirrors the production box, and then, if possible, try and get the code so that developers can run local copies on their own machines. Since you don't have version control and if you have pretty quick learners, my guess is that jumping to a more 'modern' one like git is a good bet. Subversion works fine, though.

blenderalmost 17 years ago

"Unscheduled downtime of more than a couple minutes is unacceptable any time."Sounds like HA should be your #1 priority. DRBD + Heartbeat is a one solution but non-trivial to setup. There are some high-end hosting providers (BlueLock, Terremark) that offer VMWare HA configurations.Sounds like VCS should be #2 - checkout cvsdude.com (no affiliation but we've used them and they're good)Cheers

mtwalmost 17 years ago

pretty much the standards: you need a collaboration suite (such as basecamp)I advise git for the vcs. It's fast, good for your team's setup, and powerful.Setup a test suite for your application.(unit tests, functional tests and integration)Releases are tested against the suite.If that works, it's pushed to a staging server whose database is a mirror of the production database server.Then deploy when everything is fine.

lpgauthalmost 17 years ago

testing + git + capistrano

评论 #277601 未加载

agentbleualmost 17 years ago

I have been looking into Jumpboxes for research on an article, maybe you could set up a jumpbox lamp stack that worked across all platforms for your test environment. Jumpboxes are like self contained virtual servers, and may save you some problems.