Meanbee Development Procedure in Magento 2

In this article we will be discussing how to we have setup our docker environment to develop Magento 2 extensions.

Meanbee has a good amount of experience with Magento 2 projects, however Magento 2 is still a young platform. This means we are still finalising our workflow, we would love an input from the community so together we can reach standardisation.

It's no secret that Meanbee is a firm believer of open source, if we can push the community forward we will try our best to do so. Everything discussed in this article will be released on GitHub, if you spot something that you think can be improved please contribute; we love constructive criticism!

Why Meanbee uses Docker

The reason Meanbee use Docker over a tool such as Vagrant to simulate our production environments is because multiple repositories can share images. This means is that there isn't a need for a separate instance of PHP7/NGINX/MySql foreach project, like with vagrant.

Permissions are known to be a bit tricky with Magento 2 and this can reflect badly on Docker, however Nick Jones, CTO of Meanbee, has solved this issue in the environment repository.

Setting Up Docker

Installing Docker on Mac OS X

Install Dinghy

Meanbee use Dinghy to get docker set up on OS X.  Amongst other things it will do some automatic DNS routing for you.

Check the latest instructions on dinghy github but it should be along the lines of:

brew install https://github.com/codekitchen/dinghy/raw/latest/dinghy.rb
dinghy create --provider virtualbox

Once installed, add environment variables that are provided at the end of the command to your shell environment, e.g. .bashrc or .zshrc.

These are provided as an example of what to look for:

export DOCKER_HOST=tcp://192.168.99.101:2376
export DOCKER_CERT_PATH=/Users/$username/.docker/machine/machines/dinghy
export DOCKER_TLS_VERIFY=1
export DOCKER_MACHINE_NAME=dinghy

These variables can change, so the easiest way to get the correct values is to run:

eval $(dinghy shellinit)

Meanbee use a tool called Docker Compose to manage our images, this tool helps when defining and running multi-container Docker applications.

Repository Structures

So to not pollute/couple our extension repositories with environment goo, Meanbee have separated our environment setup into a separate repository. Meanbee then will include our extensions within our environment repository.

Reasons for this are:

  • Easily test in multiple environments
  • Easily add new extensions to an environment
  • Re-use our base environment in new projects

Magento 2 Environment Repository

Here is an example of our Magento 2 environment repository setup:

  • bin - Directory for commonly used CLI commands
    • run_intergration_tests.sh - run integration test for all modules in /extensions
    • run_unit_tests.sh - run unit tests for all modules in /extensions
    • setup.sh - Setup our environment, install our configured extensions into Magento via Composer
  • extensions - Directory which contains custom extensions
    • meanbee-example - A Git submodule which is installed into Magento 2
  • magento - This directory is in the .gitignore and contains the Magento install
  • test-results - This directory is in the .gitignore and is for the build process
  • .gitignore
  • .gitmodules - Contains information about our extensions
  • composer.env - Contains your credentials for composer
  • current.env - Contains setup information for xDebug
  • docker-compose.yml - Configuration for images, thanks to MageInferno as we based a lot of our images from theirs.
  • README.md

Magento 2 Module Repository

Our Magento 2 extension setup is fairly standard, Meanbee also include a docker-compose file so we can test in and isolated environment.

  • composer.json
  • README.md
  • docker-compose.ymlIncludes image for running tests in an isolated environment
  • .gitignore
  • /src - Contains Magento 2 code and is autoloaded using Composer

It's important to note, this extension is for integrating your business logic into Magento 2. You might want to keep your main business logic in another repository depending on the circumstance.

How To Get Running

It's probably more advisable to follow the instructions in the Magento 2 environment repository as they are more likely to be maintained.

The fact we have a module already configured in this repository is for example purposes, we recommend removing this and installing your own.

First you will need to pull the repository:

git clone git@github.com:meanbee/magento2-environment.git
cd magento2-environment

We have excluded a few files which provide things like your composer credentials from the repository, however we have provided some sample files, copy these and add your credentials so the repository can pull Magento 2.

cp composer.env.sample composer.env
cp current.env.sample current.env

Our modules are submodules within this repository, if you haven't already you will need to initiate them.

git submodule init
git submodule update --remote 

Finally we will need to install Magento, setup the environment and run docker-compose up -d to boot our virtual environment.

docker-compose run cli /usr/local/bin/magento-installer
docker-compose run cli /tools/setup.sh
docker-compose up -d

Scrutinizer

At Meanbee, we are firm believers in code reviews to improve the companies standard. Not only does having a senior developer reviewing code prevent bugs but it produces a higher quality of work and developers.

However, before submitting code for review we make sure first that we have submitted our custom git branch to Scrutinizer. Scrutinizer will apply a set of rules to your code any tell you how you can improve it based on your own standards.

Like with code reviews, Scrutinizer helps us find issues before they hit staging. It also will tell us our current test coverage of the desired code base, this ensures for a consistent output throughout project.

Bamboo Build For Continuous Integration

Meanbee use many Atlassian tools, these include:

  • BitBucket
  • JIRA
  • Confluence
  • Bamboo

In this section of the article I will be briefly covering why we use Bamboo.

Bamboo handles our automated builds, runs tests, releases and deployments. Not only does Bamboo nicely hook up with BitBucket and JIRA but it also it very easy to use. We have tried complicated CLI tools, which can be great however they might not always be accessible for juniors or front-ends. The interface is easy to configure but hard to break which is ideal.

Having continuous delivery is essential when following an AGILE workflow for everybody involved. Bamboo integrates with AWS CodeDeploy and docker which helps with this.