I agree with you, even though right now we have a server outside AWS for the svn and testing, we should, in the long run, put it into AWS so that it uses the exact same image.

Thanks for the comment man!

In the corps I worked in Spain they usually have the environment for developer (Eclipse, Webshere, etc…), then a development server, an integration server and production server. Some even have more environments. But actually there is ususally problems going from one environment to another, no matter how hard people try this not to happen. So, my advice would be if you don’t have too many human resources, go with just development server and production environment. I mean development server not the environment in the machine of developer.

If you have many people working on the project then play around with environments, integration ones are usufull, even more if you have domain issues with other web services, providers, etc… that need to replicate a production server.

Another problem with environments is that when many projects are uploading stuff to for example a development server, admins sometimes needs to shutdown stuff which leads to people not being able to test their apps in the development server. Amazon could help here, creating an instance for the people on that project and have many development instances only used when analyst or project managers are testing, etc…

Agree on most, small integration servers are indeed a need. Go through the path of Development server in the developer machine, then integration with more or less the same environment, and production.

With Syntax I simply use python plugin for Eclipse, that is take care of.

In deployment I use versions for all content. That is, a CSS app.css would go to S3 as app-0001.css. These files are compresses and long times in the future. I can version independent modules (JS, CS, Themes, etc…). Integration server and development server goes with app-0000.css with no future dates and loading normally. Every time I do a change in a module, generate a release in that part of JS, CSS, and the HTML will call that file. I have a deployment script that takes care of this. Loading of heavy JS content is faster this way for users visiting more than once.

I do a monitor alert, very simple, that a search is accomplished right and therefore front and back are communicating, web servers ok and services. But this area is never enough, last night found that home page had an error and did not notice (I am playing around with a new front release) and did not have development debug in Django to False, when error message shows and Email is sent with error. Still, the better monitoring you can afford the better.