I remember a couple of years ago I spent many hours searching for how to move from development to production. I was so confused. I am an experienced developer, but I have always done it wrong. I knew I was wrong, but I didn’t care at the time (shame on me).
Let me clarify, I did care. I wanted so desperately to do have a development environment and to stop making stupid mistakes in production, I just didn’t have the know how. Everything I read seemed to talk over my head, and I just didn’t understand. It seemed like I needed to know what I didn’t know to do what I wanted to do that I didn’t know how to do.
So what have I learned? It’s more about workflow and processes than a single answer. More like, find a workflow and stick to it. In the end, the chosen workflow only matters if you use it and stick to it.
Because I am currently the only developer, I use a simple workflow that works for me. I am committing all day and when I have something that works, I want it in production as quickly as possible.
My Workflow:
- My development and production files are on the same machine. I do this because I was used to working in production anyway, and I know that the environment is the exact same (Apache, mysql, memcache, all my tools)
- I use GIT for version control. (This was a huge stumbling block for me, I had started/stopped version control SOOO many times over the past years. It was hard for me to see the value as a sole developer with no “releases” to speak of.)
- I have a continuous integration server (phpUnderControl).
- I follow the Git-Flow model (very loosely)
- For daily work/small changes, I work directly on the develop branch. (THIS IS NOT A BEST PRACTICE)
- For extended large changes, I use feature branches (ALL WORK SHOULD PROBABLY BE DONE THIS WAY)
- When I am ready for something to go into production I have a “bumpVersion.php” script that automates most of it.
One of the biggest problems I had before this workflow was constantly saving a file and assuming everything worked. Sometimes I had syntax errors that I didn’t catch right away. With git hooks, I have it setup where I can not commit a file into the repo unless it passes php linting. This is run with php -l filename, which just checks the file for syntax errors. This has saved me many times since having this workflow.
My bumpVersion.php script:
This is a simple script that allows my git tags to be numerical (sequentially) and for my tags to be named in a consistent manner. It will also handle some other tasks if necessary, such as compiling/minifying javascript and CSS. This actually does quite a bit, by putting these assets into RackSpace CloudFiles and waiting to make sure they are available before continuing with the build. This prevents any changes from going into production until all the assets are available. In the end, it uses git flow release start/finish to create a release tag, this merges everything into the master branch. The script then pushes the master branch into a bare repo.
phpUnderControl:
phpUnderControl is constantly monitoring the bare repo for changes. As soon as it detects some, it does a git pull, runs the unit tests, if successful it then publishes the build. This really entails a simple call to another script that does a git pull from the bare repo into production. (THIS MAY NOT BE A BEST PRACTICE).
Conclusion:
Don’t be afraid when coming up with a workflow.