Creating a development workflow with supporting documentation
In the process of migrating to a new server environment for the university’s websites, we figured it would be a good time to take a look at our current processes and try to improve them. The next wayne.edu is going to live on these servers, so it was important that these changes fit our needs.
We ended up making some major changes to our development workflow over the past 2-3 weeks. We also started to document that workflow. Anyone in our department can now follow a hand full of steps to setup their machines to allow them to contribute code.
- We decided to switch from using SVN to GIT by using github.com. This change alone has been a huge improvement.
- Branching and forking repositories is so much easier. This has allowed us to truly have our own testing environment for new additions without having to jump through hoops.
- Pull requests are done when a branch is ready to be merged with master. This has allowed us to have developers submit their code for review prior to it being merged. It allows for an overall discussion of the code and the ability to comment on specific lines of code.
- Ability to have bugs, enhancements and discussions tied directly to code. You can reference commits in comments to show exactly how an issue or feature was resolved.
- README.md – This file at the root of the repository has allowed us to define specific instructions pertaining to that repository. It’s shown when you pull up the repository through github.com using markdown to make it easily accessible.
- You can have a wiki for each repository to organize your application.
- We’ve now setup our applications/sites so we can work locally on our machines using mamp.
- This allows us to have our own testing environment so we aren’t competing against each other to test code on our development server.
- A lot of time is saved since load times are instant.
- It allows us to use codekit to automatically refresh the browser (another time saver), compile SASS/Compass the same way, and to minify our css/js for production use. It saves a json file to the root of your project so the config settings for codekit can be synced between all developers/designers.
Deploying to Development/Production
- We are now using capistrano to deploy our websites instead of manually publishing files to each server.
- Our process is that you can deploy any branch to development for testing, but only the master branch can be deployed to production.
- Capistrano allows for releases of your project on the server. If something goes wrong on deploy you can easily rollback to a previous release to get the site working again.
- We are logging each deploy using loggly so we have a record of who is deploying and at what time.
These changes to our workflow have boosted productivity for me by an indescribable amount. It feels so much better working this way. I’m very excited to see over the next couple of months how we can expand on this to make our workflow even better. If you’ve ever thought about changing your workflow for the better, do it. The time spent changing it is worth it!