Deploying web site(s)

I looked at cruise and really liked its pipeline, as it gives QA the ability to push buttons and deploy code manually once it passes manual QA. But the funds don't appear to stretch that far. Is there an equivalent, or a workaround, in TeamCity? I'll be using Phing, which I know I can use to update working copies & deploy that way, but our QA (and therefore deployment) team are non-technical, so whatever I use needs a pretty and intuitive interface. Command line is out. I also don't want to go reinventing the wheel, cos the dashboard for TeamCity/Cruise do an excellent job of telling people what is deployed where.

I can't make these deploy configurations dependent one after the other, the QA team need to sanction the code moving from test -> QA and from QA -> live.

Our codebase is too big to zip and move around, we make probably over 100 changes to the websites a day but they're small - people don't want to wait half an hour for their changes to go live. I introduced deployment via SVN for one system & people got sick of waiting 2 minutes, so ingrained is the 'go-live-now' ethos. So my preferred method is to keep the working copies within the agents on each machine and just rsync the changed files to where they need to go, via very simple scripts, once approved by QA.

Anyway back to my original question - is there a way to manually run a stage, not trigger it via the commit to SVN? Or is this the wrong tool for the job?

Many thanks

Ben

4 comments

OK - so I'm a dummy. I can just set the VCS settings to update automatically, but set the build trigger to manual. Sorry for wasting ppls time.

Given that the 'build' which is actually just a deploy to QA, will always succeed, is there a way to manually mark a build as having failed, and mark it as unsuitable for release? I'm considering a hack of adding a further stage which sees someone creating a file somewhere with the result, and have a subsequent stage check that.

Also - Rollback. I found the way to deploy a previous build ( run a custom build, choose last change to include seems to take the working copy back down to the desired number) - but the number displayed still shows eg build 38 passes, gets deployed, bug then found so rolback to 37 - number alongside still displays 38. Is this the expected behaviour?

0

There is no way to manually mark build as failed, but you can add comment to the build, and in history and on build overview it will be marked with additional icon.

As for custom build, maybe you could attach a screenshot?

0

Thanks. None of the tools I've seen have a manual fail, seems a shame as a lot of testing is through interaction and can only be decided by a human.

Here are some screenshots of the custom build stuff. What I was trying to say is that, although I've rolled back to #54, it still shows #57 (Picture 11.png) - you have to drill down to the build overview to see the actual last build which was run (Picture 12.png). If this is expected behaviour that's fine, we'll just have to display the webintegration and webproduction screens at all times.

Ben



Attachment(s):
Picture 12.png
Picture 11.png
Picture 10.png
0

Regarding manually failing builds, please watch/vote for this issue: http://youtrack.jetbrains.net/issue/TW-2529

It seems I understand now. You mean that even if you've created a custom build on a previous revision (#54), overview page still shows build #57. This is by design.
In most cases developers need to see builds with latest changes. Otherwise, consider a situation when build #54 fails. If we would show it as the last one on the overview page, what should be the status of configuration? I guess, it should be green, because build with latest changes is green, but this would be very confusing, seeing the last build red, but the configuration status still green.

History builds are considered out of changes sequence, and are ignored in many places. For example, TeamCity won't send notifications if history build fails.

0

Please sign in to leave a comment.