Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Right now I'm using Mercurial to synchronize similar Apache configurations between the production and development servers. A patch queue on top of that adds in the changes and extra stuff required for the development server.

The scheme works but it could be better. I always get merge conflicts when I reapply the patch queue after pulling changes from the deployment configs. I feel like I am always making identical changes to the separate http:// and https:// config files.

How should I factor out the identical bits between my :80 and :443 Apache configs and more cleanly add in the "extra bits" to the development config?

share|improve this question
add comment

3 Answers

up vote 5 down vote accepted

You might want to consider using the Include feature of Apache's config system. Then separate out the elements of your config that are specific to an individual machine into a _local.conf that should make the merging simpler

share|improve this answer
add comment

Apache has an option to selectively enable certain configurations. This lets you use the same config file for development and production. Start apache with -DDEVELOPMENT or -DPROD, and you can use tags for configuration that is specific to the dev server. This way you won't get any merge conflicts (unless you change both dev/prod config files before merging of course)

share|improve this answer
    
+1 Useful. Here is an example: <IfDefine Custom> #Anything you want in here </IfDefine> Then run "apache -DCustom" or "httpd -DCustom" depending on linux flavour. –  Coops Jul 14 '09 at 14:56
add comment

This may be old school, but my stage and production apache configs were identical, except that some of the parameters within each were different (ie: IP address). I used a perl wrapper around a start script to 'fill in the blanks' in a methodical way. The actual base config 'templates' were indeed identical.

This insured that the stage apache was functionally identical to the production apache.

Sharing this production config with development enabled them to test as close to production as they wanted (and they wanted to, because they would not get into production unless their stuff 'worked' in stage. We supplied help occasionally (for mod_rewrite rules for example) and left the rest up to the developer.

Difference between this particular setup and other places I've worked are:

developement staff were encouraged to dabble in areas not directly related to the programs they worked on... ie: they may work on back-end applications (thus wouldn't need to know much about apache) yet they configured their own apache servers (in fact built their own desktops, but that's a line crossed IMnsHO).

operations actually drove a lot of the infrastructure, rather than just running it.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.