Sometimes, you get spoiled by how things are done in organizations. I am having one of those moments today so I figured I should write about it. A good development environment needs a source of truth and a clear separation of concerns.

1) Source control is your source of truth. Anything not in source control did not happen. If you make a live edit to a file on the production server it is gone with the next update. This should never be allowed to happen. This is why I do a lot of deployments out of my  continuous integration server. The only way to deploy is for the server to get the latest version from source control and install it on the server. If it was not important to put into source control it was not important.

2) Be careful managing your database(s). I usually recommend each developer runs a local database. This way changes to the dev database don’t break other peoples code until you check your source code in. Having a system where change scripts are checked in an run can be troublesome to implement but it is worth it. The benefit being that when you migrate to your different environments you have a suite of scripts already written. Ensure these are in source control

3) Verification is a time consuming process. Having to diff filesystems and databases to find the truth is a time consuming process that is fraught with errors. One project I am inherited has source in four (or more) locations so establishing which is the most current is a frightening process.

4) Establish the different environments very clearly and limit access where appropriate. If you have a mess of servers with some running production and test and development you are going to hit points of confusion or have inadvertent updates to applications. It is simple enough to accidentally update the production database by accident if they are on the same server as your development database. I have always felt that developers should have almost zero access to the production system where possible. Yes, it makes it easier to debug but there are ways to allow developers to debug without making changes (e.g. access to the event log, read only access to the database / filesystem, etc.). I avoid even that due to security implications but if you need to then there are better options than admin rights to the production server.