views:

23

answers:

1

hi all,

we use svn(subversion) for our source repository. On the same box, we build our project PLUS deploy it onto an appserver. All the team members(under 10, in number) will login to the Linux (ubuntu server) box and run the build script.

Question : I would like to know which directory is typically used for creating the home directory for the subversion checkout and doing the build. What type of permissions should I be giving so that the teammembers can come in to that dir, update the source code(svn update) and run the build script (ant).

P.S : I'm also interested in any understand best-practices.

Thank you,

A: 

Sounds like you need a Continuous Integration server. Install Hudson on the server and use that instead.

Hudson will automatically check out changes from Subversion and build them when something is checked in. You can also make it deploy to an app server after a successful build. And you can trigger builds manually if you want, for example for a release.

You'll find it very easy to get started with.

Christoffer Hammarström
I've considered using Hudson. For this team of junior developers, it would help that they understand how to login to the system(linux) and then run a script to update the source code and build the target PLUS deploy into tomcat. Then at a later stage, we can have non-technical users come and use a Hudson based build/deploy system.
anjanb
@anjanb: A Continuous Integration server is for developers, not for non-technical users. It's used by the developers to automatically keep track of the status of the project.
Christoffer Hammarström
Hi Christoffer, I've previously used Jetbrains Teamcity and know that the primary target is Developers; However, currently, we will need a build system that let's users(devs and non-devs) kick off builds(and deploys). Before using such a system like Hudson to let anyone come to a webpage and kick off a build, I'd like that the developers login to the system and run a build script. This would let them understand what is under the hood of a continuous integration system. Not sure if I am clear ?
anjanb
I don't understand? Are you saying that your developers don't know how to build the system? Your developers should already be running `svn update` and `ant` as they are developing on their own machines, and the process should be exactly the same on the integration server, just that there is no point in doing it manually when Hudson can do it automatically.
Christoffer Hammarström
Plus, the integration server should be using the same Tomcat deploy ant task or script as the developers are using to deploy. There should be no technical difference between an integration build/deploy and an individual developer's build/deploy.
Christoffer Hammarström
Christoffer, thanks. Devs are today using windows using tortoise to checkout and checkin code and run ant script; however, Our build server and deploy server run Linux. also, we prefer to deploy to production server only from the build server(linux). Right now, only me and another engineer builds and deploys to production. I'd like me NOT be a bottleneck and would like all developers to, at the least, be able to log into the build server, svn update and deploy onto tomcat. ** For this purpose **, I wanted to know which directory (and permission) to check out the code to. Makes sense ?
anjanb
Hudson sounds absolutely perfect for your needs, seriously. The developers can log into Hudson and either watch while Hudson automatically triggers a build, or they can manually press the "Build now" link. If they're interested in what commands are being run, both the build configuration screen and the build log are just one click away. Hudson has its own workspace directory which it checks out into by default. At least try it?
Christoffer Hammarström
Also, when i say "developer's build/deploy", i of course mean they deploy to their own local Tomcat installation, not to the production server. I do not consider that a "technical difference", more a logistic difference. The exact same steps are still done by both the integration server and the developer, just triggered differently.
Christoffer Hammarström