This really goes hand in hand with my last post, Monitoring.

One thing I don’t get is why in production, most logging is shut off in my favorite PHP framework, Symfony. To me, logging is necessary to determine the state of your application. Along with updating metrics for use in graphs, a log message should be logged for the same kind of events. This gives you some forensics to determine problems that occurred. Even more, you can log all sorts of information to be able to determine what went wrong where.

For instance, someone complains that their account was hacked? If you log the IP and user agent of the person who logs into an account, you’ll be able to look into your logs and determine what happened. If you’re also logging incorrect logins, you’ll also be able to see what other accounts that IP tried to log into.

Always log exceptional and nominal events that occur in your application. Your log level should be set to INFO not ERROR in production. You should be able to go through the logs and see what’s going on. It will also help you determine what new security features and bug fixes need to be planned.

At my previous companies, there have been two ways of putting code onto a QA or production server. FTP the files up or svn up a checkout of the production branch.

But builds are so much cooler. You can have a build process that runs unit tests and other code analysis, removes unit tests or other things not required on the production server, and then packages this up into a tarball or zip. For this, I use a very simple phing build script. Phing is a great tool built for PHP that allows you to accomplish tasks like creating builds. A simplified version of this is as follows:

There’s a bit missing from this, but you get the idea…

Once you have this build, it will be exactly the same no matter where you put it. There’s no worrying about which revision number you’re on, you have a simple build number that’s ready for deployment.

Then, once you have this build, you can deploy it anywhere you want. While you can use phing to deploy, my favorite deployment tool is Capistrano. There’s a great extension to Capistrano called capifony, which adds tasks to capistrano that are symfony specific. I further extend this to allow deployments to other environments than production, switches for the build version that I’ve created previously, and all applications that I create are deployable with one central capistrano build.

All in all, I think that’s so much cooler than FTP.

When developing some application or website, I cannot stress how much it helps to use virtualization. It may seem like an overcomplication, but having an exact (or nearly exact) replica of the production environment helps immensely.

For instance, when developing my mafioso game, I found a problem where on the Hackintosh that I’m developing on, Macports uses version 2.0 of MongoDB. When I deployed on my Debian 6 server, I found that the version of Mongo installed was 1.4! If I had been using a virtualization of Debian 6, I would have seen that I was developing on a version of MongoDB that was not available in my target environment.

Going back to real life experience, at my current company I created a VMWare instance of our production environment. I copied the production memcache, php, apache, freetds and other configs that we use in production onto our image. Then, you can be sure that the features that you’re using, and the errors you’re experiencing can will be the same as production. If you need to install a new package in order to use some certain functionality in PHP or likewise, you will need to note that it’s a requirement for deploying the feature being developed.

Virtualization also gives you an environment that is separated from your desktop. All the crazy things that you might do in your desktop are isolated from the environment of your virtualized server. What you see in the virtualization is what you should see in production.

Also, you can upgrade that virtualized image to a new OS to test the upgrades to your applications that will need to be performed when the upgrade happens when the upgrade happens in production. Virtualization helps you isolate changes to a specific environment change.

Lastly, virtualization is sharable. The configuration you have done on your local development environment is local to your desktop. When you include virtualization, you can just copy the image to the other developer’s desktops.

If the source code is loaded by a share or an NFS partition, then the only thing that can be different between production and development is that loading of the source code itself. Which will lead into the next topics… Deployments and builds.

One other very important part of virtualization is this. If you develop on OSX (or some other environment), then you still want to see whatever x% of people see. In this case, you install Windows XP, Vista and 7+ in a virtual machine. Load that machine up, and check out IE 6,7,8,9 plus whatever differences there are in Firefox and Chrome on Windows, and see the issues immediately. If you develop this discipline, then you will see issues that people stuck on these operating systems will see before they become an issue.

In my next posts, I’ll post a series! These are the lessons I’ve learned while at my current job. The topics will include:

• Why Virtualization is cool
• Builds and Deployments
• Monitoring
• Logging
• Unit testing
• Why CMSes suck
• Cool tools
• Documentation, documentation, documentation!

I’ll include a link to these posts in this post as I make them!