State of development at Evermade 2017
Sometimes it’s good to sit down and analyze your technology stack and the direction it is going. I did that for our company Evermade and wrote down my findings. I’ll try to do this as a yearly thing. It would be nice to see how we are progressing. I did this for mostly to myself but I hope that this will also help other companies as well.
Key technologies
As a WordPress agency our key technology is quite obvious: WordPress. HubSpot is definitely an emerging platform and we have made HubSpot integrations and HubSpot-only websites. For shops, we use either WooCommerce or Shopify. In addition to that, we have created services with the Laravel framework. We have used technologies like Ruby on Rails, ExpressionEngine, and OpenCart and we are still supporting projects using these but not offering any new business for these tools.
Primary tools
We store our code on BitBucket and manage scrum projects with Pivotal Tracker. For client communication we use Basecamp. It might not be the best tool out there and I think they messed it up on version three. But it’s still handy for messaging with clients and saving conversations in one centralized place. We keep passwords safe with 1Password. At the beginning of the year, we reviewed other alternatives like LastPass and Dashlane but decided to continue with 1Password. It has clearly the best team capabilities.
Development environment
Our team is working on virtual Ubuntu Linux virtual machines running on a cloud. We are not limited by local hardware resources (ex. Vagrant is very memory extensive) and we can easily work remotely with virtually any laptop available. Even on our phones if sh*t really hits the fan! Our servers are located in UpCloud’s Helsinki datacenter and latency to our office is minimal. We are mounting to local folders so that we can use local tools for editing.
We are heavily utilizing Docker in our dev environment. Docker is basically the only tool we install and all tools are run as a container. Say if we would like to run npm, instead of running:
npm install
we execute npm inside the docker container:
docker run -it --rm -v $(pwd):/app onefastsnail/node-bower-gulp npm install
This completely eliminates a need to install tools and in that way, we make sure that we are all using the same versions of tools. To save our keyboards we have created a wrapper for those complex Docker commands. This all saves tons of time.
Each project is shipped with a Docker stack. We are using NGINX + PHP7-FPM + MariaDB.
Developers can freely choose their editor. Sublime used to dominate but these days at least one of us uses Atom and a few uses Visual Studio Code (which is my choice as well).
WordPress
We use Composer for dependency management and we have a private repo for private and paid plugins. We use Gulp to merge source from different sources (vendor, custom themes etc) to create the actual WordPress build.
All settings are configured in a single environment variable file which is used everywhere (wp-config, deployment config, Gulp etc).
We try to avoid excessive plugin usage and carefully choose what we install. These are the plugins we are using on almost every project:
- ACF for extending the WordPress data model.
- Gravity Forms for forms.
- WP Super Cache for caching.
- WPML for multilingual sites. We have tried Polylang in a few projects but it has it’s problems as well.
- Yoast SEO for SEO.
Each site has a development environment(s), staging environment, and production environment. We used Capistrano for deployment and database migrations but it was quite complex and therefore error-prone. A few years ago we switched to Flightplan.js which is a simple Node-based server automation tool. Because of its simplicity and the fact that it’s JavaScript almost anyone on our team knows how to configure it. I don’t know anyone else using Flightplan.js which is not usually a good thing 🙂 We are planning to switch to Ansible for deployment & migration. In the end, our deployment is a simple rsync command wrapped with some fancy automation around it.
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 staging environment before deployment. We are monitoring our WordPress fleet with an in-house tool called Carebear.
We try to separate logic away from our theme to plugins. This is something we need to improve on.
Front-end / Theme
We have created our own base theme called SWISS. The name comes from the Swiss army knife and the idea is to provide a base for different kinds of needs. SWISS defines where to put your SCSS, JavaScript, and templates. It also provides boilerplate code for the most common building blocks which allow us to create basic functionality pretty quickly.
We are using SCSS which is then compiled to CSS. We used to use full Bootstrap but now we are just using the Bootstrap grid mixins. BEM naming convention helps keep things organized.
Bower is used for frontend dependency management. This is something we are planning to switch to npm or yarn.
SWISS comes with a bunch of pre-written JavaScript which is heavily based on jQuery. We have plans to rewrite the whole stuff with Babel / native JavaScript.
React is our choice for more complex front-end stuff with simple Flux implementation or Redux. These are becoming more and more common.
Production & servers
Although Docker is heavily utilized in the development environment, we are still hosting our sites on traditional Ubuntu-based LEMP servers. Servers are provisioned with Ansible and mostly hosted on UpCloud. For some projects, we are using more complex setups.
The whole production architecture will be redesigned in the future to be more automated, robust, and most likely Docker-based.
Things just around the corner
We have been experimenting with automated end-to-end testing tools and created a pretty nice set of test suites with selenium-based Nightwatch.js. It’s still not widely used on all projects but definitely emerging.
Continuous integration and delivery are also something we have been experimenting with. Travis? Pipelines? Jenkins? We don’t know yet – maybe next year I’ve more to tell 🙂
Conclusion
I honestly hope that opening our way of working gives ideas to other people as well. Also if you think that we are missing something or doing something stupid feel free to post a comment!
Ps. If you think this stack is something you would like to work with, we are looking for developers 🙂
