Note: This is a work in progress. I will finish the rest after the presentation. I just wanted to publish the post to link to. If you have any questions, please post them below I will try to answer them as fast as I can. I probably won’t have time to finish this until Sunday, due to several critical projects that are due ASAP.
This in the “In-Depth” part of my presentation on “Streamling Web Development with SVN & Trac.” I can’t possibly cover all the aspects of this topic. I like to post a “in-depth” article right after my presentation with links, tutorials, and all my resources used for the presentation. This allows for me to spend more time on questions & answers. I’d appreciate any feedback on the presentation, and if you have any questions feel free to ask. This article is an extension to the presentation, so I suggest listening to the presentation first if it seems like there are any pieces missing.
Here is the Scribd version of my Presentation. Since it didn’t like some of the things I used in the presentation, I uploaded a pdf version as well.
As a web developer, I like to spend the most time possible on adding improvements, making changes, and ensuring quality. What I don’t like spending time on is repetitive tasks trying to manage the project. Over the last few years, I’ve been trying to focus on “automating” the processes of web development, letting programs, scripts, and othe technologies keep me focused on real development. I’ve pooled together all the information I’ve found on the subject, and hopefully I can help anyone searching for more information.
The Development Cycle
There is one constant in any type of software development: change. Every project is going to have new features, bug fixes, feature changes, etc. Our goal is to help create, verify, and deploy these changes as quickly as possible, while ensuring quality. There are five basic steps, in my opinion, to this cycle:
- Code Changes
- Test / QA Changes
- Stage Changes
- Deploy Changes (Push Changes Live)
This is where developers get down and get their hands dirty. To be honest, this is my favorite part of the process, as I would think most developers would agree. However, if we only focus on this aspect, our products will suffer from bugs and errors.
I use SVN to manage all of my code and my changes. “Subversion (SVN) … is used to maintain current and historical versions of files such as source code, web pages, and documentation.” (Wikipedia) Basically, it is a great tool to manage your source code, whether it is PHP, HTML, CSS, JS, Images, etc. If you are unfamiliar with SVN and source control concepts, I highly recommend visiting the online SVN Book. The chapters on Fundimental Concepts and Basic Usage are great primers for SVN. To give a tutorial on SVN is outside the scope of this article, so I would suggest reading & experimenting with SVN before trying to continue this article.
Important steps to working with SVN is that you must be able to run your website code locally. Some beginners (myself included when I started), use SVN like a glorified FTP, using it to upload their files to the server, and “commit” hundreds of tweaks and changes in a short period. Soon you will have thousands of revisions that aren’t meaningful. Running your code locally, by either installing your enviroment or using a local server (physical or virtual), you can make a single “change” that you’ve tested & ensured before “commiting” it to your SVN repository. This way you review your SVN repository history, each revision is meaningful. With good commit comments, you will see “Added extra field for middle name on registration” in the history, and all code changes needed for that one “feature change” will be in a single revision entry.
There are many tutorials for running your code locally. If you want to install Apache, MySQL, and PHP on your machine, I suggest using XAMPP. It works with Windows, Linux, Mac OSX, and others. I have a video tutorial for installing XAMPP on windows.
If you want to investigate using Virtual Machines for a local test environment, I would suggest checking out Sun’s VirtualBox. It is Open Source (GPL) and I like to use it when I don’t want to pay for the expensive VMWare solutions. There is a great article on using a Virtual Ubuntu Server as a local development enviroment. This tutorial is based on using VirtualBox to virtualize Ubuntu within Ubuntu. Cal Evans takes the same approach, but you can read how he tried doing it using a windows environment.
Testing / QA Changes
Once you’ve coded and tested your changes locally, you commit your changes to the SVN repository. Using a post-commit hook with SVN, we update
Here is a diagram showing the basic setup for streamlining a project with LAMP, SVN, and Trac.