aspose file tools*
The moose likes IDEs, Version Control and other tools and the fly likes how to make build environments  like one for development , another for testing , & production ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » IDEs, Version Control and other tools
Bookmark "how to make build environments  like one for development , another for testing , & production ?" Watch "how to make build environments  like one for development , another for testing , & production ?" New topic
Author

how to make build environments like one for development , another for testing , & production ?

kenji kunoichi
Ranch Hand

Joined: Jun 02, 2007
Posts: 46
I have started a project with few of my friends. I know in time it will go large and may go out of control. So for better management I want to make separate build environments like 1 for development , one for testing another for production. How to do that ? what kind of hardware / tool do I need ?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16240
    
  21

Don't.

It's better to create a product that can be identical in all 3 environments. Otherwise when you have a production error, you're not testing the same app when you go to debug it, and there's a very real danger that sooner or later the wrong edition of a product will be deployed to the wrong environment (speaking from sad experience).

It takes a little more care to create a "universal" app. You can use JNDI and deployment descriptors to setup and inject information into web apps. Configuration files are the usual mode for stand-alone Java apps, with properties files being the favorites.


Customer surveys are for companies who didn't pay proper attention to begin with.
Peter Johnson
author
Bartender

Joined: May 14, 2008
Posts: 5842
    
    7

Here is what we do. We use Subversion to store our source code - everyone checks their changes into it. You could use git or some other source control management system, it doesn't matter which one you use, but you need one. Subversion runs on its own server (not on one of our desktops). Then we have Jenkins which will perform builds from the sources stored in Subversion. Those are our "official" builds which are then possibly subjected to integration testing, and ultimately go into production. We never place into production nay code that a developer compiler or his or her desktop. Again, Jenkins, and the builds that Jenkins performs, runs on its own server. It can be the same machine as where Subversion is hosted.


JBoss In Action
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: how to make build environments like one for development , another for testing , & production ?