A modern web development workflow is key to any website project. Maintaining it and building upon it, to make it more effective and efficient should always be at the back of everyone’s mind when working in a web design and development team. Having a solid web development workflow will save time and money and will decrease project development time significantly.
In this post I write about how I work from local to live. I generally work in small to medium size teams with the workflow I am about to write about.
So, the project has been won. After weeks of pitching, meetings and spending time with the client you now have the project in your hands ready to go. Lets talk project specifications and deliverables. You should also have a written agreement and contract in place ready to start the work.
Getting the project specification and its deliverables down on paper is critical. A project scoping document basically acts as an agreement between the client and the development team. This document states everything about the project and how it should work as a final product. If for some reason the client asks for additions during the project and this does not exist in the specification that was initially drawn up, then this will be charged for as a separate piece of work.
For brief information on the previous two steps of the workflow you should have a quick read of the process page on my website.
We all have different set-ups when it comes to a local development area. It totally depends on the type of projects you work on. For me I work 100% on Apple Mac and have done for several years. I have a very specific set-up when it comes to my local development space as I work on multiple machines, a Macbook Pro at home and a Macbook when out and about working on site for companies and in coffee shops. So, my local set-up. Here’s what’s involved.
The first step is to add a “development” directory which will store all of your local websites. Because I want my local development space to be mirrored across multiple machines I create my development directory in Dropbox. I then perform the following actions to set-up a local website.
Here is what the directory structure looks like
Getting the websites to the remote repository on Bitbucket is extremely easy. In fact we have already done the hard work. Once you start adding and working on files in your local directory you will notice that Tower (or which other software you choose to use) will start recognising changes within that working local repository. Tower is now recording everything you do
Making your first commit is easy. In Tower You will see a full list of files that have been added to your local directory. To commit these files to the remote repository on Bitbucket I simply select the files I want to commit. In my case I want to stage all of my new files, so I simply select stage all which selects all buttons. Don’t forget to add a commit subject and message. This will give other developers in your team information about what the commit is about. In this area you should briefly and accurately explain what the commit is about. In my case I add “Initial WordPress Set-up Files”. Once committed, you will notice all files have disappeared. This is because they are now ready to push. Simply click the “push” button to send all files to the remote repository.
And like magic! All of your files are now backed up on you remote repository. Started editing files again locally and you will note Tower records them. Commit the files and push and you will see that the remote repository now has those new files. In bucket you can then compare files, see archived files, what changes have been made and so on. Bitbucket provides a great service all free of charge, we owe so much to its service!
Clients always like to see progress. Bitbucket keeps a backup of that progress as the project moves forward, however I would say this is more for the design and development team. Clients don’t want to see code, they want to see a beautiful working website, and we must prepare for this.
What we need next is a deployment service and then a staging server so that the client can see a working demo from a live link.
This one comes down to preference again. I prefer to keep all of my demo sites on my own dedicated server. To do this I simply set-up a sub domain for whatever the project is I am working on e.g. https://qualitybooks.glenwheeler.co.uk. I then provide the sub domain with certain services and features such as a database, the latest version of PHP and anything else that the website demo requires. Once this is set-up I will then have space to deploy my files to. All files will be pulled from my Bitbucket repository. This might be from a development or master branch on Bitbucket and could consist of the latest committed files or a selection of committed files, which ever the developer requires.
A note on database versions. It’s hard to keep on top of database versions. Databases are not included in your commits from local development to BitBucket. At the present time the best way for me to do this is to keep updated database versions in Bitbucket by uploading the SQL dumps to the file area on my BitBucket Account. There is however a service I recently discovered to manage database versions a little better. This service is called vizuina. It’s not something I have looked into deeply yet, so I will comment more on this once I start to use it a little more, I might an article on it at a later date. Maybe you would like to comment on this one at the end of this post? It’s one problem I know a lot of development teams struggle with.
We’re lucky enough to have some great deployment services available to use these days. My favourite, and the one I use on a regular basis is Deploybot (formerly Deploy.io). The service enables me to deploy my code anywhere I need to using its simple to use web application interface. The application comes at a very cheap price of around £11 a month and is well worth the money. Simply create an account, login, create a repository, connect it to your Bitbucket account, select the repository from Bitbucket, add and configure it’s environment and then add the staging server ready for deployment. Just like other services I have mentioned in this post, there are also other alternatives to Deploybot. Some of these are DeployHQ, Beanstalk, Codeship and Travis CI.
Deploybot offers a wide range of deployment options including Digital Ocean, Heroku, SFTP, FTP, Shopify, Rackspace, Atomic SFTP and Amazon Web Services. You also have the option to use Shell by running your commands and deployment scripts
Once you have configured the deployment service of your choice, you are then ready to push the button. Click “deploy” and you’ll see your files will start deploying from bit bucket to the staging server. Deploybot will send you a notification once the deployment process has complete. If for some reason the deployment process fails, you will also be notified of the issues ready foe debugging. Be sure your database is in place on the staging server and is configured correctly with your configuration.php file or what ever file you might be using to connect your website to the database.
Just like that, your website which has taken the journey from your local machine to a live staging server is complete.
Now that we have a full web development workflow in place, all we do now is just follow the process right back around again starting from step 5
Below is a diagram which shows the development workflow I have written about above. The diagram outlines the simple steps to the workflow.
As I have already mentioned in this post, everyone has their own workflow which they are comfortable with. There are probably parts of my workflow that you find confusing, incorrect or none preferred, but it’s what suites me and allows me to work quicker and more efficient. Time is expensive so don’t waste it without a workflow in place.