In some ways, web development is no different from building a house. You need a solid foundation - no way around it. So, having your IDE all set, you still have to cover going from a local environment to staging or production. That’s where we at Osom turned to CI/CD Buddy. Works tool.
CI - Continuous Integration
Every time we change anything, a set of tests should run. It’s a bit more work at the beginning because CI requires a list of tests, but not having those tests in the long term will lead to bugs or problems that can eat up all of our saved time. Trying to say we don’t have time for testing is a lie in the long term.
What else can you do in the CI part apart from testing?
A simple answer would be that it’s all about automating the boring manual things that have to be done every time. Not everything can be automated of course but each thing we’re going to have automated is a thing that saves us time and from that point on we know that the task will be done consistently. This can help everyone with optimizing work at an agency, it saves money in the long term, and it allows the client to be much calmer during deployment. From the business side, it’s a very good decision because we deploy using a tool like Buddy.Works we don’t need to have a “Maintenance mode” turned on which in the e-commerce websites could mean that we would lose money with each deployment.
CD - Continuous Deployment
Every time we pass our tests we build all of the files and automatically upload all of them to the server.
It allows you to automate a deployment starting with getting the files from a repository, getting all of the packages, building all the files, and ending with uploading. Doing all of that allows the team to start doing atomic deployments, which can be very small deployments consisting of a single task which then eases the deployment process considerably. This part is all about consistent and automated deployments without human interaction needed in between and without putting the site in a vulnerable position where using FileZilla we would only change a part of the files and would have to search for the other half.
Implementing CI/CD might be a daunting task but as a whole, it has a lot of parts that are needed to get the full effects of using this tool. If we already have a website and we want to start implementing CI/CD it might be easier to start with the deployment part of the tool where we automate building and uploading the files which means that we have an easy deployment where we don’t have to turn to apps like FileZilla. Starting the Integration part is easiest to do using built-in tests like for example the ability of Buddy.Works to take Page Speed scores for each deployment. Another step in the CI could be testing things that only need a configuration file to be built like PHPCS. End-to-end testing could also be automated without doing complicated things just by using a tool like Ghost which can record what we do while testing and turn those recordings into scenarios.
In our case we’ve built a pipeline for deployment which looks like this:
Composer update (using PHP actions) – We start by calling a composer update, we update plugins using WordPress Packagist, modules, and even WordPress Core by simply changing their version numbers within the composer.json file.
npm run build (using Node.js actions) – We always use webpack or parcel for our projects. This action allows us to compile files so we don’t flood the repository with compressed files.
SFTP transfer – The last step in our pipeline is to upload our built files to the website FTP server
What we would like to say is to start slowly and don’t rush the process because you can burn your team's trust in the tool. Start with things that won’t break your flow. Give automation a try because it’s the glue that keeps everything together.