State of development at Evermade 2017

Sometimes it’s good to sit down and analyse 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 a services with 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 the version three. But it’s still handy for messaging with clients and saving conversations in one centralised place. We keep passwords safe with 1Password. In 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 runing 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 utilising Docker on 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 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 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 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 few uses Visual Studio Code (which is my choice as well).

WordPress

We use Composer for dependency management and we have 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 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 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 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 it’s 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 our Evermade Care plan. We have disabled automatic updates and we are using composer to update dependencies. Sites are tested on staging environment before deployment. We are monitoring our WordPress fleet with 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 swiss army knife and the idea is to provide a base for different kind of needs. SWISS defines where to put your SCSS, JavaScript and templates. It also provides boilerplate code for the most common building blocks which allows 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 keepings things organised.

Bower is used for frontend dependency management. This is something we are planning to switch to npm or yarn.

SWISS comes with 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 utilised in 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 automated end to end testing tools and created 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 is also something we have been experimenting. 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 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: