Beta/Dev to Live Management

Solarpitch

Hey Guys,

In a company I work for when were developing a new project, website or application we have 2 cuts.. a dev and live version. We work off dev then transfer all files over to the live version manually. There are also seperate databases for each, a dev and live DB.

There has to be a better way of deploying changes in a dev enviourment to a live version? Is there any enviourment that manages this. We develop in Aptana/Eclipse and submit code to an svn repository.

There must be some way that we can easily submit changes from Dev (including the DB table changes) to live. Maybe some way that the current live version checks the dev to see what has changed since the last release, and just commits those files?

amen

well going Dev- >Live is not a good idea.

What we do is Dev-> Internal Test ( sign off by internal QA required)->Customer Test (Sign by Business users and customer QA) - >Live.

Seperate DBs, Servers etc for each environment.

When we move from Dev->Internal test we build a release package and/or SQL script for the Database. This is then run on each environment as move through each stage.

If there is an error then we go back to the start and rebuild again.

Solarpitch

I see,

With SVN were able to create different branches and trunks which we have done so for a few large projects. We'd have a Alpha -> Beta-> Dev-> Live set up.

What I'm finding difficult is trying to manage the different versions. Does your IDE manage this for you? Have you a centralised CMS but create a brand new cut for each release?

amen

We use MS TFS.


Basically we create a Release and apply to test and away we go.

If we need to make additional changes its a new release.

Occassionally we do make an out of sequence patch release but it is rare

firefly08

There has to be a better way of deploying changes in a dev enviourment to a live version? Is there any enviourment that manages this. We develop in Aptana/Eclipse and submit code to an svn repository.

You might want to look into continuous integration using something like Hudson

With this, you could run an automated cycle that would safely handle getting all your updates from dev to live: you make a change on dev, commit your code to subversion, Hudson picks up this commit, checks out the latest code, builds it, tests it, and if is passes, deploys it to live. It sends you emails to let you know when it passes or fails tests and when it deploys something.

I put "tests it" in bold because having automated tests is important (more important than usual) when you're deploying automatically! Otherwise you can break everything just by committing your code! I have seen this many times, with developers who are not used to continuous integration - checking in a "fix" at 4pm on a Friday and buggering off, and the target environment is down for the weekend. Even with tests, I still recommend a separate test/staging environment, and defer deployment to a live environment until some manual testing has been done - unless 'live' is really not critical (i.e. nobody looses money if it it's broken for a while)

Of course Hudson is very configurable - you can have it only deploy new tags, so that you can commit your code, test manually, and then tag when you're happy with the code, and Hudson will do the rest. It's well worth having a dedicated Hudson machine. There's nothing like a team-wide email saying "Tom broke the build!" to instill developer discipline.

Solarpitch

firefly08 wrote: »

You might want to look into continuous integration using something like Hudson

With this, you could run an automated cycle that would safely handle getting all your updates from dev to live: you make a change on dev, commit your code to subversion, Hudson picks up this commit, checks out the latest code, builds it, tests it, and if is passes, deploys it to live. It sends you emails to let you know when it passes or fails tests and when it deploys something.

I put "tests it" in bold because having automated tests is important (more important than usual) when you're deploying automatically! Otherwise you can break everything just by committing your code! I have seen this many times, with developers who are not used to continuous integration - checking in a "fix" at 4pm on a Friday and buggering off, and the target environment is down for the weekend. Even with tests, I still recommend a separate test/staging environment, and defer deployment to a live environment until some manual testing has been done - unless 'live' is really not critical (i.e. nobody looses money if it it's broken for a while)

Of course Hudson is very configurable - you can have it only deploy new tags, so that you can commit your code, test manually, and then tag when you're happy with the code, and Hudson will do the rest. It's well worth having a dedicated Hudson machine. There's nothing like a team-wide email saying "Tom broke the build!" to instill developer discipline.

Thanks for that and agree with what you said above. We're going to be having a review next week so I'll have a look over hudson tonight to see what it offers but I like what you described. AT a glance seems to be the solution we're after.

I'll let you know how I get on with it.