Improving our development environment at work

Question

In the near future i will get some 2 weeks for moving and improving our development environment at work.

We mainly develop one large PHP/MySQL project with 2-10 developers.

At the moment we have one dev server, running apache with mod_userdir, each dev has a /public_html folder in his (samba-accessible) home. For VCS and Project Management/Issuetracking we use Subversion and Trac. Testing/Deployment takes some manual steps, not much automation there.

My plans for the new setup include the following changes to the existing stuff:

• Continuous Integration
• Integrate CI to Trac, create/find a plugin which offers to start actions after success or failure of the build progress (i.e. deploy to staging/live)
• Create automated deployment-scripts (one-click)
• Integrate (doxygen)-Documentation into the build-progress and somehow into Trac
• Add automatic versioning
• Add another layer of monitoring (local nagios monitoring our production-system-nagios)
• Add a nightly running MySQL Replication Slave, which can then by the developers be used to test stuff on up2date data
• Review the backup plans
• Document how and why I set everything up in this way

Do you have any tips/hints what can be improved further? Anything we should do in a different way?

Turkic

Answer 1

I would make sure that you write your automated deployment scripts in such a way that they can be used by your continuous integration tool. Hudson (and CruiseControl I suspect) basically wrap these scripts and provide a nifty front-end.

Hundson is easy to install and comes with a Trac plugin, SVN, CVS, Git plugins and a Doxygen plugin and others for almost anything you can think of. Caveat: I haven't used all these plugins and they may not do exactly what you want...

If you have a budget for CI software then TeamCity is well worth a look (or are you using Bitten?).

You've a great opportunity, so good luck!

Cohesion

I like Hudson - the underlying attitude of the programmers shine though. – Moralez

Answer 2

My only suggestion would not be to spend to much time on the

• Document how and why I set everything up in this way

This is the last item on my list for improving our development environment and I still haven't done it.

Each part is always being modified or improved to provide us better functionality or easier use. I would suggest trying to keep the "why" as comments as close to where you actually implement it as you can. This is the only place someone changing your system will need it.

Perhaps also one big diagram showing links and names of physical servers but other than that I've found the documentation to be a hassle.

Cheers

Azar

It is often more productive to tell this in a meeting, where you draw stuff on whiteboards and photograph the whiteboards afterwards. Then send the photos to all attendees. An hour can save you days of typing :) – Moralez