Good Practices for Web Development Project Management

Question

I realize that the phrase "good practices" is a bit dubious and overused, but I think it applies to my question.

I have some good web development experience, but I would like to hear what are some good basic practices when doing freelance work vis-à-vis project management.

For example, I have the target domain, mydomain.com. Should I do all of my testing at a subdomain, i.e. dev.mydomain.com, protected by .htaccess or some other means?

I am familiar with SVN, but not for web development. What's the best way to version control a website?

I have set up two databases, mydb_dev and mydb_rel. Does it make sense to do all of my work on _dev then transfer the structure to _rel? What happens after the first release?

If you can answer some of these questions or link me to a good resource it would be great. My searches so far have only yielded HTML tutorials!

Answer 1

As for version control, I'd say put everything under control that isn't dynamically created. For example, if you're application generates a bunch of .txt files on the fly, you don't need to version those, but anything that is created just once, needs to be under version control.

As for your choice of version control system, I'd recommend something other than SVN (probably Git or Mercurial), but that's more just my personal preference than any substantial reason.

Answer 2

What we do.

1. Use a framework that allows testing outside a deployed web server. We develop and test on laptops. Some folks use Glassfish running under Eclipse for testing. Other use Django, which runs stand-alone. We have databases on our laptops for development and testing. We use configuration files to be sure that we're using the "development" names for databases, directories, etc.

2. Do integration testing on a VM. Our hosting is Red Hat Enterprise Linux-based, so we have Fedora VM's that we use for testing with Apache and MySQL (or Oracle) and that whole technology stack. We have integration test databases in the VM environment. We use configuration files to be sure that we're using the "test" names for databases, directories, etc.

3. We use products that have very tidy deployment. Glassfish/Java applications are deployed with WAR or EAR files. Django applications use Python's setup.py installer. That way we can install into production, fiddle with the database, and we're up and running. We use configuration files to be sure that we're using the "production" names for databases, directories, etc.

The first release involves building the database the first time. We provide a script (or in the case of Django, we run the manage.py syncdb command) to build the database.

When making schema changes, we either have scripts or instructions. We have to do it in test and again in production.

When deploying to the visible to the world production, we do this.

1. We have a VM in our hosting environment that's "staging". We get this to work. It's not visible to the internet. We checkout our components, install them, run the DB schema change script (or do the manual steps if it's complicated). Usually, we work on a copy of the production database.

2. We then clone that VM to create the production VM. We change the production configuration to use the upgraded copy of the production database.

We don't have a database named "prod", that's hard to work with. We have "prod_3" in production, "prod_4" in staging when we're doing our upgrade. Then we change the configuration file to use "prod_4". "prod_3" can hang around until we need the disk space to create "prod_5".

Answer 3

What I would generally suggest is the following. The team should have 3 kind of "deploy" environments:

• development environment: This is where developers work and can publish
• test environment: This is where tests are done, also showing possibly to the customer. Only working products should be deployed here.
• production environment: The final deployment of the running and used product

Here's something that treats this concept. What I would suggest is that the "test environment" (or pre-release environment) lies on the same server with the same configuration as the final "production environment".

To what concerns version control I would use it just for versioning source code. You can use whatever version control (or even configuration management tool) you like. Here it is a good practice to do branching, so whenever you release a product (deploy it to the production environment) you create a branch with a corresponding version number to it. In parallel you continue to develop on the main branch. This has the advantage that you can do possible bugfixing that may happen to your release and you can redeploy the branched copy without redeploying new features that in the mean time have been added on the main development branch. Search the web for best practices on branching, there is a lot of stuff around. I wouldn't however use SVN or something for versioning your website directly..at least I've never heard of such a practice. Better way would be to create backup copies of your production environment in a daily fashion on the server somehow...

Answer 4

A few tips I've found helpful in my own work:

• I maintain a personal wiki page for each project that contains all project-related data. Since it's just for my personal consumption, I can organize each one organically as needed.

• Keep a questions log (on the wiki page or elsewhere) that crop up throughout the course of the project. Rather than bombarding your client with random emails or accidentally forgetting to ask a question in a timely fashion, keeping a log will let you send one coherent and compiled email every few days with project-related questions.

• Do all development locally (MAMP, XAMPP, etc). This way your client is never accessing the website when you're working on it, therefore bypassing unnecessary confusion (why I am getting blank screens now?!? They were working 5 minutes ago!!).

• Push from local development to your staging server via Capistrano. This can be done again for production. Much easier to keep track of any build scripts (minifiying JS, for example) and is much more efficient than FTP

• Use SVN to manage all assets - content, templates, comps, your working site, database exports, etc. A well-organized repo won't get out of hand if you set it up right from the start. Never hurts having an extra backup, even if you know you're never going to touch a file again.