Automation

We think of automation at several different levels, from the way a developer does their work to way we build and deploy applications.

Use better tools

We encourage our developers to use the most appropriate tools for their work. Modern integrated development environments (IDEs) – like PhpStorm or Netbeans for example – not only have excellent code hinting and code completion but also lots of plugins and extras for important things, like, for instance, PHP Code Snifferarrow-up-right integrationarrow-up-right in PhpStormarrow-up-right or Xdebugarrow-up-right integration in PHPStormarrow-up-right.

Task runners and dependency managers

There are many task runnersarrow-up-right and packager or dependency managersarrow-up-right that both help to automate the developer's work and aid in conforming to industry standards and best practices.

Frontend

Task runners such as Gruntarrow-up-right, Gulparrow-up-right are important and useful frontend development tools, for tasks such as:

  • Compiling and minifying CSS

  • Compiling and minifying JS

  • Compressing images

  • Watching for changes and running certain tasks on file change

  • Refreshing the browser on file change

Frontend dependencies should be managed with a package management tool, the most widely advocated being NPMarrow-up-right with Browserifyarrow-up-right (though other optionsarrow-up-right are available, in certain circumstances).

Backend

We advocate PHP development using the Composerarrow-up-right dependency manager as much as possible. Composer is becoming increasingly-well supported by open-source PHP software projects and the de facto standard for building PHP software distributions and projects.

Other similar dependency managers are available and should be employed for other languages and technologies.

Continuous integration

We use continuous integrationarrow-up-right automation tools (and the process and practices associated with continuous integrationarrow-up-right) to continually build the development environment, run tests and return results. Automated builds are usually triggered when code is checked into the designated branch of the code source control repository, for example, after a feature pull request has been successfully reviewed and merged.

This practice ensures errors are detected early by the development team, so they can be fixed and prevented from escalating or being accidentally deployed to production.

Build it when you need it

An important benefit of automating the process of development and deployment through continuous integration is that many tasks can be run on the deployment server (dev, staging, QA, production or wherever) during deployment. Automated tasks, especially those covered by package and dependency management, can be run on the server by the automation tools themselves. This saves unnecessary code from being committed into the project repository, keeping it clean and reserved for project-specific code only.

Continuous deployment

Continuous deploymentarrow-up-right or continuous deliveryarrow-up-right is the natural extension of continuous integration. Changes made to the system are constructed as 'releasable' and these releases are then pushed to production automatically.

Continuous deployment is designed to make releases boring so the project team can deliver frequently and get fast feedback on what users care about.

Last updated