What are your Development Environment Setup/Management Best Practices?

Question

I have always found setting up a project development environments overly time consuming and difficult. I would like to know your best practices for setting up an environment.

Some difficulties I found with environment setup include:

• Keeping the environment up to date with latest patches vs. synchronized with other developers
• Inconsistent file paths between developers that leads to different configuration files
• Unable to reproduce a setup without difficulty due to undocumented steps/information
• Documentation is time consuming
• Conflicts with older projects (i.e. multiple servers on same ports or changed PATH variables)

More specific environment questions include:

• Do you create an environment setup document? Have you found this successful?
• When updates are released for your current setup, what do you update and what do you keep constant? (IDEs, 3rd party plug-ins, libraries, etc.)
• If you use a repository, what setup components do you recommend storing in it? (setup documents, software installs, libraries, databases, drivers?)
• Does anyone use disk/system images and/or VMs to synchronize developer environments?
• To what extent do you reuse setups between projects? (whole environment, project, code)?

Thank you and please add any questions or difficulties you have.

Answer 1

For the most part we have our dev setup automated through ANT scripts.

Our builds will build and assemble our apps along with creating required config files and scripts for all of our environments.

We can then deploy a complete environment based on our build results. On our dev servers we do have to separately install app servers, db servers, etc. But other than that we can say "deploy a complete env" which will deploy all the application files, libraries, config, scripts, etc from our build results.

Answer 2

I find that it is best to specify as little as possible about a development environment. Typically I would only specify the version of Visual Studio to be used. And the means of connection to the repository. After this everything should be checked in. Libraries should be checked in with whatever code needs them so that nothing is needed other than a get and a build.

Apart from this it is important that there is a one step build script that respects these contstraints. I should be able to install my OS. Install visual studio. Connect to the source repository. Do a full get. and be able to build straight away.

It is important to respect that developers like having their machine set up in different ways. Specifying as little as is neccesary recognises this, and keeps everyone happy.

I feel that code and libraries are the only thing that belongs in the code repository. Everything else should be stored elsewhere. design documents are best stored in a document management system, though a seperate repository can be used in a pinch.

Finally all software should be stored on a network share. It is great to have a large store of of software with appropriate licences so that developers can install it if needed and dont need to go searching the web. But it dont reccomend installing it on a new build machine. Let people control their own working environment.

Answer 3

• Make sure that your projects/solutions are atomic (For example see recommendations on organization of solutions and version control repository setup)
• use continuous integration to enforce development discipline around the projects
• use build scripts to automate mundane or repetitive tasks
• keep to DRY principle where possible

Answer 4

Do you create an environment setup document? Have you found this successful?

• We have a company-wide wiki on which we document what a developer needs to get started. This has basic stuff about Eclipse and what plugins it needs, among other things. It's useful for the basics, but we try to make our processes as easy as possible so that we don't have huge write-ups just for environment setup.

If you use a repository, what setup components do you recommend storing in it? (setup documents, software installs, libraries, databases, drivers?)

• Everything that the project needs to build and deploy as simply as possible is checked into SVN. Our projects should be able to be deployed quickly:

  svn checkout svn://path/to/repository my-project
  cd my-project
  ant deploy
  

  We also check in Eclipse project meta-files (e.g. .project, .classpath, .settings/) so that developers just need to do an import in Eclipse to get up and running.

Inconsistent file paths between developers that leads to different configuration files

• All of our builds are path-relative (with the exception of deploying, they build within and below the project's top-level directory). Our build can be parameterized (with a build.properties) if a developer needs to deploy to a different location, but the build (as used above) is intended to work out-of-the-box with no additional configuration.

Does anyone use disk/system images and/or VMs to synchronize developer environments?

• We use xen for virtualization. We've created an image that we can clone that has a lot of the stuff we need, such as ant, tomcat, and a lot of other little things. If we need a new deployment environment for whatever reason, we can just clone this VM, check out the source, and build onto it. It's very convenient.

Answer 5

I'd love to have any suggestions or tips about the below.. Better to learn than to suffer through it yourself!

I keep all server side software (Svn, etc) installed on virtual machines. A nightly process backs up the virtual machines.

When hardware goes south, I can quickly copy everything painfully configured to another machine in a matter of a few minutes and be up and running with minimal downtime to my environment.

I have one OS X Server running:

• 1 VMware image for bug tracking/project management (Fogbugz on Windows Server 2003)
• 1 VMware image as a source code repository (SVN, etc on debian)
• 1 VMware image as a development server (with mysql)

I may get rid of the os x server and run VMware's free ESXi platform as I don't use the OS on the Mac very much.

Storage of data for all these vm's are done on a central partition.

Performance testing is done on a real server.

The next thing I would like to do is get automated builds working with ANT, there is some priceless information on this site for that.

Answer 6

MAVEN

-Keeping the environment up to date with latest patches vs. synchronized with other developers -Inconsistent file paths between developers that leads to different configuration files

all the configuration is in the pom file (except developers local configuration like path to jboss or jdk)

-Do you create an environment setup document? Have you found this successful?

we dont, you need to setup few paths and if you dont project will not build.

-When updates are released for your current setup, what do you update and what do you keep constant? (IDEs, 3rd party plug-ins, libraries, etc.)

pom is being keep in svn(its has hardcoded version numbers of liberies and its dependencies)

-If you use a repository, what setup components do you recommend storing in it? (setup documents, software installs, libraries, databases, drivers?)

we store only source code, we use maven proxy to store lib and every developer has downloaded only libs that he need(by maven)

-To what extent do you reuse setups between projects? (whole environment, project, code)?

we use parent pom or super pom that has all the main configuration and hardcoded versions number of libs. all the poms inherite the configuration and sometimes override something if its needed.

plus maven allows you to use any IDE, it just need to have maven plugin or you could even use command line to build projects. maven has really good support and you can even depend on environment in your build(for example if you use linux you can use that lib, if windows other one).