Question

Web developing isn’t what it used to be. It used to consist of hacking together a few PHP scripts (I have nothing against PHP, actually it’s currently my main programming language), uploading them via FTP to some webhost and that was that. Today, things are more complicated. As I can see by looking at a number of professional and modern websites (SO being the main one, I consider SO being a great example of good practice in web developing, even if it’s made with ASP.NET and hosted on Windows), developing a website is much more than that:

1. The website code is actually in a repository (that little svn revision in the footer makes my nerdy feelings tingle);
2. Static files (CSS, JavaScript, images) are stored on a separate domain;

Ok, these were my observations. Now for my questions:

1. What do you do with JavaScript and CSS files? Do you just not keep them under version control? That would seem stupid. Do you create a separate repository for them?
2. How do you set up the repository? Do you just create one in the root of the web server? Or do you create some sort of post-commit trigger that copies the latest files to their appropriate destinations?
3. What happens if you have multiple machines running the website and want to push some changes to all of them?
4. Every such project has to have configuration files. These differ from the local repository to the remote one. For example, on my development machine I have no MySQL root password, while on the production server I certainly have a password. This password would be stored in a config file, amongst other such things, which would be completely different on my machine and on the server. Maybe they are different between production machines, too (like I said earlier, maybe the website runs on multiple machines for load balancing). How do I handle that?

I’m looking to start a new web project using:

• Python + SQLAlchemy + Werkzeug + Jinja2
• Apache httpd + modwsgi
• MySQL
• Mercurial

What I’d like is some best practice advice on using the aforementioned tools and answers to my questions above.

Answer 1

You’re right, things can get complicated when trying to deploy a scalable website. Here are what I’ve found to be a few good guidelines (disclaimer: I’m a rails engineer):

1. Most of the decisions regarding file structure for your code repository are largely based upon the convention of the language, framework and platform you choose to implement. Many of the questions you brought up (JS, CSS, assets, production vs development) is handled with Rails. However, that may differ from PHP to Python to whichever other language you want to use. I’ve found you should do some research about what language you’re choosing to use, and try to find a way to fit the convention of that community. This will help you when you’re trying to find help on an obstacle later. Your code will be organized like their code, and you’ll be able to get answers more easily.

2. I would version control everything that isn’t very substantial in size. The only problem I’ve found with VC is when your repo gets large. Apart from that I’ve never regretted keeping a version of previous code.

3. For deployment to multiple servers, there are many scripts that can help you accomplish what you need to do. For Ruby/Rails, the most widely used tool is Capistrano. There are comparable resources for other languages as well. Basically you just need to configure what your server setup is like, and then write or look to open source for a set of scripts that can deploy/rollback/manipulate your codebase to the servers you’ve outlined in your config file.

4. Development vs Production is an important distinction to make. While you can operate without that distinction, it becomes cumbersome quickly when you’re having to patch up code all over your repository. If I were you, I’d write some code that is run at the beginning of every request that determines what environment you’re running in. Then you have that knowledge available to you as you process that request. This information can be used when you specify which configuration you want to use when you connect to your db, all the way to showing debug information in the browser only on development. It comes in handy.

5. Being RESTful often dictates much of your design with regards to how your site’s pages are discovered. Trying to keep your code within the restful framework helps you remember where your code is located, keeps your routing predictable, keeps your code from becoming too coupled, and follows a convention that is becoming more and more accepted. There are obviously other conventions that can accomplish these same goals, but I’ve had a great experience using REST and it’s improved my code substantially.

All that being said. I’ve found that while you can have good intentions to make a pristine codebase that can scale infinitely and is nice and clean, it rarely turns out this way. If I were you, I’d do a small amount of research on what you feel the most comfortable with and what will help make your life easier, and go with that.

Hopefully that helps!