State of Development at Evermade 2019
Our team of developers keeps a hawks eye on digital technologies and trends. There are two main reasons for this: 1. We ensure that we can provide the best possible solutions and support for our clients, and 2. We maintain a steady development curve on both an individual and a company level.
Below, we have listed the philosophy underlying our work, key technologies and tools we use, and our development practices.
Non-technical reader: proceed at your own risk.
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 for 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 a direction. We experiment and try new tools all the time. When we find something interesting that works for us, we merge that to our workflow pretty soon. Everyone is allowed and encouraged to suggest changes.
Key technologies
Backend and frontend separation is becoming a more and more common paradigm. On the frontend side, React has definitely emerged – almost all of our projects have at least some part of the frontend written in React. Headless technologies are another rising star that we’re beginning to implement more and more.
In the past, Evermade was clearly a WordPress agency, but with growth we are able to build on other technologies as well. For content websites, WordPress is still our number one choice. Our way of working with WordPress is advanced and our site creation framework Everblox proves strong time after time. REST APIs are everywhere and almost every project includes some integrations. We have been working on some Contentful sites as well.
For e-commerce projects we use both Shopify and WooCommerce. Currently, there is no need to go changing this setup.
Primary tools
Our primary tools have remained pretty much the same for a couple of years. For versioning we use mainly Bitbucket, but for our open source projects we use GitHub. Scrum projects are managed by Pivotal Tracker and for client communication we use Basecamp.
Editors
Our developers are free to use any editor as long as they understand .editorconfig and their choice supports Prettier. Visual Studio Code is the most popular one but also Sublime Text, Emacs and Neovim are used.
Cloud based development
Our team works on virtual Ubuntu Linux machines running in the cloud. Working in a virtualized environment provides a few clear benefits compared to local development:
- We can work with virtually any laptop available.
- 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 mount to local folders so that we can use local tools for editing. Cloud-based development does currently have two major drawbacks:
- It’s more expensive than local development since we need virtual servers for everyone.
- It requires a stable internet connection, so sometimes working on the go and in remote places can be challenging.
We have had discussions about moving towards local development especially now when Docker on OS X has matured, but no formal decisions have been made yet.
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 tools we install locally and everything else is run inside a Docker container. Say one of us would like to run npm install. Instead of installing Node locally, we use the official Node Docker image:
docker run -it -w /app -v $(pwd):/app node:8.11.4-jessie npm start
This may look frightening at first, but there are major benefits to doing so. This approach eliminates the hassle with people having different Node versions and makes working with legacy projects so much easier. If you need Node 6, 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. We build all tools, environment requirements and dependencies to the project. The only thing we need to do is to build a docker image and start working.
Continuous delivery
At the moment we are working on a continuous delivery setup which will build our projects in the cloud and deploy to staging and production environment. And in future run tests as well. We experimented with CircleCI and Pipelines and ended up using Pipelines. It builds the project in the cloud and uses Docker for deploying code to servers.
Working with WordPress
We have created our own WordPress boilerplate called DockerPress for starting new projects. We have used tools like Bedrock but ended up creating our own, because no existing solution completely fulfilled our needs.
First of all, as mentioned, we Dockerize everything. We use Composer for PHP dependency management. For proprietary packages we have our private Composer repository. Webpack bundles JS and SCSS files. We have separated dependencies and our own code and use Gulp to merge and build the final product (this is something we will drop in future releases). For configuration we use single environment file which we pass to a Docker container running WordPress.
Plugins
We try to avoid excessive plugin usage and carefully choose what we install. These are the plugins we use on almost every project:
We use our own base theme called SWISS, which we released to the public this year. Everblox is one of the core features of the theme. It’s a way of building the site with horizontal building blocks.
Each site has development environment(s), staging environment and production environment. On our latest DockerPress version we dropped out Flightplan and Ansible. We used Flightplan for deployment, database pull/push and other automation tasks, but it will be replaced by continuous delivery. Ansible was used to provision servers. Ansible’s biggest benefit comes from using it to orchestrate and manage an entire infrastructure during its life cycle. However, we used it only for initializing server, so we switched to a more simple approach: init bash scripts.
We offer WordPress maintenance as a service, as part of our Evermade Care plan. We have disabled automatic updates and we are using composer to update dependencies. Sites are tested in a staging environment before deployment.
Front-end & React
We use SCSS and BEM naming convention. The SWISS base theme has a lot of pre-written CSS-code which we can be extend for project needs or even extract to other non-WordPress projects. We used to use full Bootstrap but now we are just using the Bootstrap grid mixins.
Basic Javascript on SWISS is built with jQuery. For complex functionality or non-WordPress projects we usually go with React. We don’t have a strict boilerplate for React, so it’s the developer’s responsibility to pick up the best tools. These are some of the libraries in use:
- Redux
- Redux-thunk
- Redux-saga
- React router
- ImmutableJS
- Reselect
- Styled components
We have also experimented with Vue. It’s a great alternative to React and easy to learn. However, we are trying to focus on React to keep our stack consistent.
What’s next
Analytics is an integral part of understanding how we succeed in our projects. Understanding analytics and integrating it more deeply to our workflow, and bringing in analytics related features are our key goals at the moment.
Headless tools like Gatsby.js are definitely interesting. Static sites are secure and fast, and they really separate backend and frontend. We’re hoping ship more projects like this in the future.
WordPress’ new WYSIWYG editor Gutenberg will be released during the upcoming year. It’s one of the biggest changes in years and it also overlaps slightly with our Everblox. It will be interesting to see what Gutenberg is capable of and how that changes the industry.
Automated testing is also something we want to make an integral part of our workflow. Now that we have continuous delivery in place, we can focus on bringing testing and A/B -testing in.
It’s always nice to polish our development environment and tools, but at the same time we want to focus on ideas and features that bring direct benefits to our clients.
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 between freedom and limitations.
Let us know what you think. Are we missing something or doing something that makes no sense at all?
Happy coding!
