Describe the best deployment environment you've worked with [closed]

Question

The Joel Test includes the question:

Can you make a build in one step?

Which is important, but I'm wondering, how streamlined have some of the deployment processes been?

All software from shrink-wrap to web applies: what's the best deployment environment you've worked with, and what steps were involved?

Answer 1

It's the environment I have set up in my company, and am working with right now.

Description of the environment

We are a team of 4 developpers, working on a Java desktop project. The source code is under Mercurial, with the main repo hosted on our development server. We mostly use TortoiseHg to work with Mercurial. The projects that we open sourced are on BitBucket. The project is built with Maven. The IDE we use is Netbeans, which works impressively well with Maven (it works ok with Mercurial, too).

Our dev server runs Archiva, which is a proxy Maven repository. We use maven to build the project, but we use it also to execute it (mvn exec), to deploy the generated artifacts to Archiva (mvn release), and to generate an assembly from the artifacts hosted by Archiva (mvn assembly).

We have a Redmine bugtracker too, and it is aware of the Mercurial repos. We use a RSS client to be informed of the project activity (from Redmine and Mercurial). We also have a Jabber server to send messages and files to each other.

We set up an Hudson server (continuous integration) and a Sonar server (code metrics). But in practice we don't really use it.

We have the choice of using Windows or Linux

Steps to make a release

Example to release a version 1.1.3

# tags the VCS, updates all the version numbers in the maven config file
mvn --batch-mode release:prepare -DreleaseVersion=1.1.3 -DdevelopmentVersion=1.1.4-SNAPSHOT
# performs a clean build, runs all tests, deploys to the server
mvn release:perform
# creates a unique jar (the final product) from the previously deployed artifacts (no recomilation involved)
<update the version number in a config file to 1.1.3>
mvn assembly:assembly

Answer 2

I used fabric to setup deployment in my new startup.

Updating the live server is as simple as:

fab prod upgrade

This gets all of the latest source, puts up a maintenance page, migrates the database, sets up the new code, gets all the dependencies, stops/starts everything, etc. All of the pertinent information (passwords, usernames, etc.) are all asked upfront.

I just run the command, input some info, and go get a cup of coffee. Everything's all live by the time I get back.

Answer 3

I'm not sure I agree with Joel on this one - surely no steps are better than one?

We use Hudson to script our builds (continuously on both Mac and Windows), including building installers and CD images for the few times we actually send out a real box. We always test from the installer in QA.

We also use Hudson to copy the installers to the "beta" area of our live website once per day.

So essentially we can deploy to users every day in no steps. When we make an official release, we just switch the filenames of the installers in CMS to make the current beta installers the release ones, and change the Ant build script to switch to the new version number (which becomes the new beta).

Having this set up and working makes release day a complete non-event (which is exactly what it should be). We've not had a mistake on release day for a while now (it used to be a regular occurrence)!

Answer 4

At one of my clients, we work in Rails and have everything set up so that the deploy pulls from git. We don't "build," though, since it's Rails.

So the deploy process is something like

git checkout review
git merge whatever-that-was
git push
cap review deploy:migrations

The mix between Capistrano and GIT works out pretty well.

Of course, further scripting would be in order to skip some of these steps.

Answer 5

My current workflow is like this.

1. Develop on local VM
2. Test, Commit changes, push to github
3. ssh into EC2 and pull changes

This can all be scripted into one step.

Answer 6

We have a Java Web Start application - we are about to rebuild the deployment procedure to be as a WAR file with the JNLP file being adapted to the URL requested when requsted by the users.

I expect that to go extremely smooth.

Lately we have used git a lot. The idea of registering deployments in git repositories so you can simply ask git to checkout the version you want to run. Background updates, very short checkout time to update actual files, very short checkout time to roll back to a previous version in case of problems. I think it could work very well for us.

Answer 7

Granted this is now rather dated, but I used to have the following be the steps to deploy my code many moons ago that I found to be the best I've had:

1. Check-in my code changes into Visual SourceSafe.
2. Get Latest Version on my boss' machine.
3. Compile the solution that produced a few DLLs.
4. Show that the new code worked like it should.
5. Disconnect the production server from the Internet to update it without interference.
6. Copy the binaries onto the production server.
7. Start IIS.
8. Redial back into the internet on the ISDN line used.

This was back in the late 1990s when I was programming in Visual C++ on NT 4.0 for a dot-com. Most of the deployment processes since this have gotten more complicated in having nAnt tasks and other extra stuff like dealing with load balanced production servers whereas back in the day we just had the one production box.

Course handing the process over to a release engineer is better but isn't quite the same as if I put the code into the wild.

Answer 8

Not for nothing, but right-clicking on an ASP.NET web app and selecting Publish was a nice, pleasant surprise when I had to deploy an app. Granted, I had to set up the virtual directory and such on IIS beforehand, but deploying new versions is a few clicks away.