State of development at Evermade 2020

It’s time to update our state of development blog post again. Previous versions from 2017 and 2019 are available here and here if you are interested in how things have evolved. We write these primarily for two reasons:

Jaakko Alajoki, August 31, 2020

1. To contribute to the community. We hope that others can learn something from this, and I’m also hoping to get feedback from the community if we are doing something incredibly stupid.
2. To tell potential developer candidates what kind of stack and tools we work with. Most of the people applying to work with us have read these posts.

This post is not the shortest, so please take a cup of warm (or cold) beverage and jump in. 

Balancing between freedom and limitations

Developers like freedom. In a perfect world, you would be able to pick up any tool you like, or at least the one that best fits the project’s requirements. While this is an appealing idea, reality will almost always limit your freedom. 

But limitations aren’t just a bad thing. Having a set of guidelines will help unify processes and projects and produce consistent results. We’ve identified three main benefits of having a boilerplate and some guidelines:

• Resourcing is easier – people can jump into other projects with minimal friction.
• Maintenance is easier – different people can develop and maintain the same projects with minimal struggle. 
• Increased productivity – Unified tools help everyone to improve and become more productive.

Our guidelines aren’t meant to restrict creativity, but rather give it direction. We experiment and try new tools all the time. When we find something interesting that works for us, that gets merged into our workflow pretty soon. Everyone is allowed and encouraged to suggest changes.

Key technologies

Evermade’s mission is to “help organizations realize their online dreams.” That’s quite vague – as missions often are but practically from a development point of view that means building websites, webshops and services. I would say 80% of our revenue comes from WordPress projects. Some could call us WordPress agency and there’s nothing wrong with that even though we are always open for options and alternatives if that makes sense. 

HubSpot has gradually gained popularity and it could also be counted as one of our core tools. We now have one team focusing solely on HubSpot projects. 

From Javascript frameworks React is nowadays an integral part of our work and our go-to framework for more complex front-end features and web apps.

For e-commerce projects, we use both Shopify and WooCommerce.

For non-WordPress backends, we have used Node.js and Express-framework.

Primary tools

Our primary tools have remained pretty much the same for a couple of years. For versioning, we mainly use Bitbucket. Moving to GitHub has been in discussion for ages but currently, we are depending on Bitbucket Pipelines and switching to GitHub wouldn’t be worth the effort. For our open source projects, we use GitHub. For project issue tracking we use Trello. Basecamp and Slack are used to communicate with clients.

Editors

Our developers are free to use any editor as long as they understand .editorconfig and their choice supports Prettier. Right at this moment, every one of our developers uses Visual Studio Code (list used to be longer including Atom, Sublime Text, Emacs and Neovim).

Cloud-based development

Our team works on virtual Ubuntu Linux machines running in the cloud. There are definitely a few benefits of working in a virtualized environment compared to local development:

• We can work with virtually any laptop available.
• A centralized cloud environment is more secure compared to the option where projects are stored locally on laptops.
• Environments are equal, which helps us to trace down and debug issues. 
• Everyone can access all instances. It’s easy to help a friend out and continue others’ work if someone is unavailable.

Our servers are located in UpCloud’s Helsinki datacenter and latency to our office is minimal. We are using VSCode’s remote editing or SSHFS to mount a remote filesystem.

Cloud-based development does currently have two major drawbacks: 

• It’s more expensive than local development since we need virtual servers for everyone.
• Some tools require special configuration since the dev environment is not run locally (for example Swagger previewing).
• It requires a stable internet connection, so sometimes working on the go and in remote places can be challenging.

Some people are working in local environments for example when working with React only or Node.js -projects. It’s mostly down to the preference of the developer.

UpCloud wrote about our stack in their blog in early 2018: Case Study: How Evermade cloudified their infrastructure

Dockerize everything

We utilize Docker heavily in our development environment. Docker and Git are the only mandatory local tools and everything else could be run as Docker containers. 

This approach eliminates the hassle with people having different Node versions and makes working with legacy projects so much easier. If you need node 12, you just use a different image. It’s also a nice way of keeping the system clean.

Each project is shipped with a project-specific Docker stack. All tools, environment requirements and dependencies are built to the project. The only thing we need to do is to build a docker image and start working.

Continuous delivery

We are using Bitbucket Pipelines for continuous delivery. When the staging or production branch is updated Pipelines automatically triggers and builds a Docker image. Pipelines also pull the latest images on production environments. Images are pushed to and pulled from Docker Hub.

Working with WordPress

We have created our WordPress boilerplate called Mayhem. It takes care of

• Setting up a Dockerized development environment
• PHP / WordPress plugin dependency management with Composer
• Dockerized staging and production configurations
• Bitbucket Pipeline configuration
• Project setup scripts

We have used tools like Bedrock but ended up creating our own because no existing solution completely fulfilled our needs. 

We try to avoid excessive plugin usage and carefully choose what we install. These are the plugins we use on almost every project:

• ACF
• Gravity Forms
• WP Super Cache
• Redis cache (if Redis is enabled)
• Polylang
• Yoast SEO
• WP Offload S3
• WP Mail SMTP

Integrations are an important part of almost any website today and we do a lot of integrations these days. Cron, REST and GraphQL are the most common ones, but almost anything is possible these days, both for importing and exporting data.

On integrations we are focusing on:

• Data safety. If the integration fails we can continue safely. 
• Privacy. Integrations usually grant access to private information.
• Monitoring. We need to know when it’s working, and especially when it’s not.
• Documentation. 

For configuring SSL/TLS we use Certbot. We also maintain constant monitoring on our certificates so we don’t get any nasty certification expirations.

Each website has a development environment(s), staging environment and production environment. We use UpCloud server environment. New servers can be easily created and initialized with server creation script utilizing UpCloud API. 

We offer WordPress maintenance as a service, as part of our Evermade Care plan. Updates and maintenance are taken care of our Care team. We have disabled automatic updates and we are using composer to update dependencies. Sites are tested in a staging environment before deployment. 

Frontend & React

We use our own base theme called Everblox which is available on GitHub. It’s an opinionated theme that’s created admin usability and development experience in mind. It comes with a carefully selected set of most used website building blocks (like a hero element, columns, listings, filter) and the theme can be used out of the box in production. However, it’s easily customizable and designed to offer a good starting point for further development. 

Currently, Everblox is based on ACF flexible layouts. We already have a Gutenberg version of it in the pipeline but it’s not production-ready yet. Our approach to Gutenberg is ACF Blocks, and recent updates to ACF came with new features previously missing.

Everblox uses SCSS with BEM-naming convention for styling and Webpack for JS/SCSS preprocessing. It supports React out of the box which makes it easy to build React components for your theme.

Basic JavaScript is written without frameworks. For complex functionality or non-WordPress frontend projects we usually go with React. We don’t have a boilerplate for React and developers are choosing libraries based on project requirements. I would say something like this is the most common setup today:

• Create React app
• TypeScript
• Redux
• Redux-thunk
• Framer motion
• React router
• Styled components

And of course, other libraries based on project requirements.

Although we have experimented with Vue and Angular we have decided to focus on React. We have been also experimenting with React Native.

Other backends

Even though most of our projects are WordPress based we are also working on a few Node projects. The stack is always selected case by case but lately, we have been using something like this:

• Node.js
• Express
• Typescript
• Sequelize
• Jest

Some projects are also using serverless Amazon stack.

What’s next

There are multiple development tracks at the moment. A lot of small improvements need to be done here and there to make our workflow more optimal. Bringing TypeScript as part of our daily workflow is one thing we are working on.

Analytics is an integral part of understanding how we succeed in our projects. Integrating data to be a deeper part of our products is very important. HubSpot is an emerging platform but it’s not the right tool for everyone. Bringing marketing automation features to WordPress is something we are looking into. 

Privacy and security are becoming more and more important and implementing features improving those are in our pipeline.

Conclusion

Phew, that’s about it! We have a lot of ideas on how to improve our way of working, but at the same time, we need to ensure a stable development stack that produces high-quality results consistently. It’s about balancing freedom and limitations. 

Let us know what you think. Are we missing something or doing something that makes no sense at all? 

Happy coding!