My first contact with WordPress was as a freelancer. At first, my development workflow was not cool at all. The process was the same for all projects: downloaded WordPress and uploaded to the server via FTP. Since I still did not know how to develop themes when I started, I bought some themes on the internet and played in the themes folder. Everything worked perfectly, in a few hours there was a website running. If I wanted to make some changes to some file, I would just go into FTP, download the file, edit it and upload it back to the server.
I worked this way for a while on small, simple projects. But then I started developing themes, plugins and working as a team on the projects. This form of work has become inefficient.
It is still common to find agencies and freelancers working this way. It’s not interesting to work like this, especially if you develop your own themes and plugins.
What are the problems with working this way?
- It has no version control, if you modified the wrong file and want to revert, you will not be able to.
- It hinders the backup.
- It is not legal to develop directly into production.
- It is not scalable, if more people are working on a single file, one will overwrite another’s file.
There are other problems, but I believe these are the main ones and the ones that give the most headache.
Today we will see some practices that can help us to have a more agile and secure workflow. Here are some tips:
1. Use a local development environment
This is the easiest problem to solve. Maybe you’re used to downloading WordPress and configuring it right on the server (just like I did for a while). Do not do that ever again. Nobody wants to get on your site, for example, and see an unfinished project, in the process of developing in the air, right? Create a local development environment and configure the project on your computer first.
All changes, corrections, additions of new features, development of themes and plugins made in this environment. This will be our amusement park.
There are a few tools for creating a local server and running our projects. Some of these tools run their local environment in a virtual machine, such as Vagrant and Docker. You can also choose to make your computer a true server by installing software such as MAMP / XAMP / WAMP or by installing PHP, MySQL, and Apache directly on your computer.
2. Do the version control of your project
I already have a local development environment configured. I can develop my plugins/ themes, make the changes and put the site up, right? Wrong! You need to do version control for your project. Here we do the version control with GIT, and we maintain the repositories of our projects in GitHub.
Why use version control?
If you type this question into Google, you will surely find a sea of links, explaining how version control works and giving you several reasons to use it. I’ll bring the ones that make the most sense to us, WordPress developers.
Let’s imagine the following situation: You downloaded WordPress and installed it in your development environment and need to create a theme. You are developing the theme, testing in the local environment and playing straight into the air (production environment), but two more people joined the team to work on the same project. How would they do it?
It would not be cool at all to get into the production environment and copy the project you’re developing, right? Even because you will continue working on that project and the version that they copied will be outdated (and yours too, in relation to theirs). When all three upload the files to the server, there will probably be some conflict. Reversing this is a problem because the server files have already overwritten. You just got a headache.
If you used version control, in this case, other developers could clone your GitHub project, make the appropriate modifications (each in your development environment), and commit back to GitHub.
In this way, everyone would always be up to date with the projects, the chance of conflicts would be much lower and even if a conflict happened, it would be much easier to solve and you would not lose the previous files because GitHub keeps the old files saved in the repository.
Did you notice how many problems can avoid with version control? Also, it is much easier to identify the errors, other developers can review your code and if the code has errors, you can revert to the previous version.
If you want to create private repositories for free, an alternative to GitHub is Bitbucket.
3. Use an approval environment
You are already developing in the local environment and you are already doing version control. The process is much better now. After testing in the development environment and make the commit of changes in GitHub, we could put the site up, since it’s all right. But there is still a very important stage: the homologation.
Everything may seem perfect to you, developer. But someone needs to test the features, layout, etc. You may have tested this in the local environment while developing, but something may have gone unnoticed by you. Other people need to test and validate what has done. This person can be a tester, another developer, or even the client.
The environment for doing these tests and validations is known as the homologation environment, or just staging. This environment also frees us from some headaches. Imagine, for example, that you only realize that the user registration is not working after a few weeks with the site in the air, or that a certain page is broken with the mobile layout.
We need to understand how users will use the features of the site and let this always align with them. It may happen that you develop a functionality expecting certain user behavior and in the end, it behaves otherwise.
4. Just put the project in the air when everything is perfect
There have been some steps up to now, we have validated and tested the project in two different environments (local and staging). The features you have developed have already been tested by third parties in staging. Other project developers have already reviewed your code (possibly some QA as well) and you have already reviewed their code. Everything is organized and there is no conflict. So finally you can put the project in the air (production environment).
No mistake should get here. We went through all these steps to make everything perfect. Any errors that go so far may affect multiple users. Depending on the error and the design, it can bring a lot of damage to the company and the customer. Great care and attention.
5. Keep your environments in sync
We configured 4 environments so far: development, GitHub, staging, and production. Be very careful that no team member skips any of the steps as it may cause inconsistency in the files. This is difficult to do, but it can happen and can make the environments look different.
If everyone works the right way, following the flow, the environments will always get synchronized.
6. Say goodbye to FTP
Many of us developers have at some point already had a love-hate relationship with FTP. If you start working by following our tips, you will not need it anymore. You may enjoy using Filezilla or any other file transfer software, but they no longer need to be part of your work routine.
All of these transfers between the environments would be rather laborious if we had to transfer the files using one of these file transfer software. What if we could copy the project from one environment to another with just one command? So we can!
How to apply this in practice?
We will cover the practical details in part 2 of this post. We will see in practice every part of the process and we will show some tools that can help, from downloading WordPress to deploy in the production environment. Things will make more sense.
The idea in this first part was to pass some tips and clarify some things about a more modern development workflow with WordPress. We brought something very close to our reality in our projects.
It is important to follow the technologies and always evolve with them, to facilitate, speed up and leave the work with more quality.
Is there anything you would like to share with us? How is your development workflow? Leave a comment.
