Ready, Steady, GitHub

GitHub is a place to make a better code. It is a community platform that works together to create better code faster. We, Visual Composer team, also use GitHub. It helps us in the process of making and refining our product code smarter, neater and faster.

GitHub users can host and review code, manage various projects and build software together with thousands of developers. It is also great for developer teams. Using the capabilities of GitHub, teams can review processes to improve product code quality.

Before I go into these processes (and share some cool links with you at the end of the post), let me tell you more about Visual Composer.

Open source requires attention to how other contributors develop the product and how to test what they add or update. This process is called “Continuous Integration” (CI), which requires a wide range of different types of tests.

Continuous Integration is a good way to keep your product in shape. That is the main reason we practice it for Visual Composer.

Today I want to share with you how we integrated Continuous Integration practice in our developers' environment.

What Is Continuous Integration?

Continuous Integration is a development practice that allows you to test every code changes in an automotive way. All code must pass tests pipeline every time you add or update your code. Tests pipeline is a list of jobs that is split into the stages.

At Visual Composer, we have two stages: code style, and test. They work in a special environment, in our case, based on docker images that use tools to complete the tasks. Most of these tasks are checks and tests.

First Stage: Code Style

As a WordPress plugin, Visual Composer is based on LAMP (Linux, Apache, MySQL, PHP) infrastructure. We code on two basic programming languages. For the backend, we use PHP (27.4% of the code) and WordPress API. For the user interface which is a frontend, we use JavaScript (48.6% of the code).

Here is an explanation of these code styles:

PHP

PHP code style is checked with the help of the PHP_CodeSniffer tool. We support the PSR-2 coding standard with some custom settings for our plugin.

JavaScript

For JavaScript, we use the StandardJS coding standard. One of the characteristics of our code style is that we don’t use semicolons after every statement.

There is also CSS/HTML code. We test it with the help of end-to-end testing which I will describe later in this article.

Second Stage: Code Tests

PHP Unit Tests

First, let's start with PHP unit tests. At Visual Composer, we use PHPUnit test 8.0.0. We make sure to use the latest versions of tools and libraries in our product. Unit testing is a quite popular way to test classes, functions and other parts of the codebase. In order to make it work, we need to create a full WordPress environment. All types of tests require some specific setup of the environment which is closer to real life.

Frontend Testing

JavaScript is based on ReactJs library which helps to create a modern interface. Additionally, there is one more library behind the code called `vc-cake`. This is our own tool that helps us to support the concept of scaleApp. You can get more information here http://scaleapp.org/.

The first testing scope is JavaScript stores or storage. You can also call them connector+ processor, which helps to connect different Component modules together. First, we write tests for them using Jest library as a well-known solution for ReactJs apps.

Then we follow with the end-to-end testing. This type of test totally replicates the behavior of the real user with the help of automated scenarios. The tests show how users are using our product form the very beginning. From the WordPress authorization, plugin activation in the Dashboard to switching between different pages on a real website.

In our case, it is a real WordPress website. With the help of handy tools, we can check every step of this “fake” user. It is not hard to write these steps but it can be quite challenging to set up the environment.

Let me explain to you more about the environment.

As I already mentioned, we need several tools for running tests. Next, I will describe when and how we integrate our tests.

Tools, Services, And Integration

Behind any practice and workflow, there are always tools. Let’s talk about them. But before that, let me tell you how tasks are created, developed and tested within all these parts of Continuous Integration.

Tasks For Developers

It is important to keep track of how the code is born. Developers at Visual Composer is a Scrum team, which means that we have boards, epics, user stories, and tasks. Before coding, we discuss and plan our work. We take user stories, one of us creates a branch in the own forked copy of the project and starts to work with the user story (and related tasks to a specific user story). In order to be finished, the task must pass QA (quality assurance) and QC (quality control). This part of testing is made by a contributor and a team from the testing department.

Codebase Storage

At Visual Composer, we use Github as a repository and are practicing the Forking workflow. It means that every collaborator should work with own repository which is forked from the main repository. Changes will be applied through so-called pull requests. Every pull request must pass the Continuous Integration pipeline. If the pull request hasn't passed the pipeline, the code can’t be merged into the master repository.

End-To-End Testing Service

Cypress is one of the leading services chosen by many open-source projects. Visual Composer is one of them. Writing end-to-end tests is a quite simple task. Yes, it requires some time for setting up the environment but once done, you can uncover very interesting cases. Plus, its community is highly supportive.

Continuous Integration (CI)

As you can see, for developing Visual Composer, we cover it from different sides and aspects. This means that we need a service/place where we can run all the tasks. Previously we were using gitlab.com service. It was quite good but being a FOSS product we decided to move to GitHub.

After some tests, we found that CircleCI works with docker images as GitLab does. So, we decided to move to CircleCI. Actually, we recreated some docker images for our tests. We used CircleCI pre-built docker images and added some staff inside the image to minimize the time to build an environment for Javascript/PHP tools.

We then took the rule that if something is broken on the pipeline it should be fixed ASAP (10 minutes). Also, every code changes should pass the Continuous Integration pipeline, meaning that all tests must be green. One thing we learned and giving you advice is to push your code to Github at least once a day. It is a good practice for every company that integrates Continuous Integration. Here you can learn more about Continuous Integration.

Conclusion

Is it enough? Of course not. Updating Continuous Integration processes is one of the topics that always exists in our minds. At Visual Composer, we keep the pace to automate the process as much as it is possible. But with one rule, never forgetting about the developers, as they are the gold of every SaaS company. That is why we are focused on what we really need, instead of what is popular. Automation is just a helping hand for human minds.

Have anything to add to my story? Leave a comment and let's have a discussion.

Useful Resources

In addition, I would like to share with you some of the resources you could find useful.

We use cookies to provide a personalised experience for our users. By continuing to browse this site, you give consent for cookies to be used. For more details, please read our Privacy Policy and GDPR section.