So how is your workflow when it comes to building a WordPress website for a client? Something like this:
- Download a file via FTP to your computer
- Make some changes to the file in your editor of choice
- Upload the file back to the server
- Look at the changes on the production site
- Not satisfied? repeat step 1 to 4
For small, new projects this kind of workflow is not so bad. Assuming that the site is not indexed by the search engines during the development and only people that know the URL will be able to see things. And even this can be overcome by using a temporary page. One big benefit is the ability for your client to watch the site in progress.
But then the site is finished, the client is very happy and takes over control. He adds posts and starts to blog. Visitors come and go and all is fine. But your client wants more. A new functionality here, some design changes there and now it is up to you: will you make those changes directly on the production site via FTP?
Of course we can debate about your workflow but a quick google on WordPress workflow will show you that most mature developers use something called version control in combination with different environments for the website. Here we will shortly discuss both version control and different environments. In upcoming posts we’ll go a little deeper into the subject.
When talking about version control you will stumble across Git and possibly also GitHub. Git is a version control tool which makes it easy to work on code in a team. All changes are stored (if you commit them often enough) and features developed by your colleague are only a few clicks away to integrate in your copy of the code. The key is committing your changes regularly. A nice history of code changes grows and grows and when something goes wrong, there is always the possibility to roll back to the previous version when all was nice and smooth.
But Git will also help to improve your workflow. By creating a new branch you are able to start developing a new feature whereas someone else might make a different branch to fix some bugs. And since it is very easy to merge different branches into the main branch when everything is stable again, you can quickly create new stuff and move the project forwards. So a well-known Git workflow works like this: The master branch is the main branch and you create a develop branch to do your development. New features are implemented in a (sub)branch of this develop branch. Once the new feature is stable it is merged in the develop branch. At some point the develop branch contains a full working version and it is time to merge it with the master branch and deploy it to the production envronment.
Development, Staging en Production environments
Version control plays very nice with different environments. Each developer has a development environment in which he typically runs the development branch of the project. Once the code in development is stable enough for the client to look at, it is deployed to the staging environment. This is a server that mimics the behaviour of the production server but which can only be reached by the development team and the client (or the managers of the team in larger projects/companies). Some feedback rounds will follow which improve the code base. Then it is time to go live: the code must be deployed to the production environment.
If you are still working directly on the FTP of the production site, we call it cowboy coding. Maybe today is a nice day to start with a little more professional approach by starting with version control. Maybe even with the setup of different environments? Of course it takes some time to adapt to this new way of developing but trust me: it is very easy to make mistakes and with a good workflow they are that much easier to solve. Happy coding!