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 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:
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).
Don’t be afraid when coming up with a workflow.