ClarityDX DevOps: An Introduction

ClarityDX is exceptionally proud of our development and engineering team, and the enterprise-grade development processes they have developed and continue to evolve. Our development team deserve a lot of credit towards the progress and success of ClarityDX, and not solely through client work, but also through our company culture and internal innovation.

This ability to go the extra mile has recently seen our dev team of five to be nominated for a UK agency business award for best web development team and in a series of upcoming posts, our Lead Developer Alessandro Senese has explained how the work they are doing around DevOps has helped the team work better, faster, more efficiently and with higher quality code output.

For those uninitiated with the term, ‘DevOps’ is a software development methodology that combines software development with IT service level of operations. The goal of DevOps is to shorten development lifecycles while also delivering fixes, features, and updates as frequently and as close to the alignment of business needs, as possible.

Below are the subjects the Dev team wish to elaborate further on, and we’ll be publishing blog posts about all of these topics moving forwards:

---

#Version Control

Version Control Systems, in particular, Git was the first tool we implemented in our daily routine, as it allows us to track codebase history and collaborate without overriding each other changes.

#MySQL

As the team started to grow, we started having multiple people working on the same project. Therefore we developed the need to have a shared database to allow multiple developers working on the same project without risk of overwriting each other settings.

The first solution we had was to share the database across one of the computers we had, though subsequently, we did invest in a small server running Ubuntu and the MySQL server.

#Monthly meetings

One of our Dev mottos is, “Every opinion matters”, so no matter the level of skill and experience of our team, It’s important to hear each individual opinion about what is going wrong and what is going well.

In 2017 the dev team started to hold monthly meetings to help define rules, improve the process and share opinions across the team. All of the subsequent ideas we implemented in the next chapters came thanks to those meetings.

#Starter theme

For our first projects, over 5 years ago now, we used [underscores.me], a starter theme for WordPress, to build websites, however, we soon realised this was not going to be sustainable for the future of an ambitious, fast-growth agency.

So this is the story of how we forked and started to custom-build our own WordPress starter theme for all of our projects on top of it.

#Coding Standards

Another challenge we have faced during growth periods was the diversity of the team: different backgrounds and experiences result in different ways of writing code, and that’s not a bad thing. What it does mean though, is that individual understanding of each code-writers way of working needs to be understood.

So, we sat down and discussed the different approaches and styles we had, and decided to implement the WordPress Coding Standards for PHP.

#DNS Server & Internal domain names

Another step we took to improve our development process was giving the ability for the Project Managers to:

1. check the status of the development at all stages
2. add content at any time during the process

Although we use WP Engine and Git to pull/push our code, any changes in the database of the staging environment were preventing us from automatically deploying our local version with the consequence of doing it manually.

So, we took our Ubuntu server, reconfigured it as a DNS server, installed Vagrant to run the website on our network, handing PMs the ability to add content using the same database as the developers.

#Gitlab

In other to have an internal website running on our server we needed a way to push our code to it using a Version Control system, preferably git.

During this discovery phase, we tested gitloite to set up our internal git hosting, but with the need of doing some code review, we kept looking until we found out about [Gitlab](https://gitlab.com/) (wasn’t so popular at the beginning of 2017 ;)).

Gitlab was the perfect choice for us, we could test it using the CE edition and so having it run on our internal server.

#Pipeline

Another big advantage of using Gitlab is its power pipeline. We started using it for simple tasks, like running gulp tasks to pushing the code to our testing and clients server. Thanks to this, CI has become a pillar in our daily working life, running Unit tests and Regression tests much more efficiently, we can assure that the new code will not break the website.

#Basta

In 2018 we started an internal development mapping process called “Basta” (an Italian word for “It’s enough”). It’s not a magic wand, nor is it the definitive solution to all of our “development problems”, however, it’s an ongoing process and methodology that we’re using to improve and speed up our development, improve quality, implement automation and manage coding standards.

Currently, our Basta look a bit like this…