Magento 2 Source Code Control with Git and Bitbucket

In this blog I will describe how we set up source code version control using Git and Bitbucket.

Klik hier voor de Nederlandse vertaling.

Our Needs

We wanted a few things for our source code management:

• Version control
• Backup
• Online access to all code and revisions
• Full access control
• Fast

Elements of the Solution

These elements played a part in our approach:

• Distinguishing between development environment and production environment
• SSH: developer keys and deployment keys
• Shop repositories and extension repositories

The Hosting Service

Choosing Git to do source code control is a no-brainer these days. Since it is a distributed version control system, it ensures that the full repository is copied to all the locations where it is used. So the source code is safe. Completely fathoming its power takes a lot of time, but the day-to-day tasks are easy to learn.

Github and Bitbucket are the most common online source code hosting services. Github is the most popular of the two for publicly accessible source code, but our source code needed to be private. Bitbucket provides free access to unlimited public and private repositories for up to 5 users. It’s fast and provides a useful web interface. We are very happy with Bitbucket 🙂

Two Types of Repositories

We create a separate repository for each shop. This repository leans very strongly on its .gitignore file. This simple file determines which files to include into the repository. We follow Alan Kent’s recommendations in this. Most importantly, the vendor directory is excluded from the repository. This includes the Magento 2 core, its dependencies, and all public third-party extensions.

The shop repository contains our shop-specific custom code, located in app/code and app/design. Also included are the paid third-party extensions that the shop uses.

Next to these shop repositories we also develop common extensions that we can use for several shops. Each of these extensions will get its own repository and is managed by Composer, just like the public third-party extensions.

Taken together, the shop consists of a main repository and zero or more of our own extensions. These extensions live inside the vendor directory and each has its own Git checkout.

Composer

Our extensions are managed by Composer, just like any other third-party extension. To add an extension to a shop, we add an entry to the repositories section of composer.json:

This tells Composer to add our Git repository to its list of Composer repositories, the places where it looks for packages.

Next, we tell Composer to add our extension. If the extension is still under development, as is often the case, we must add the @dev stability flag. This tells Composer that it must ignore its minimum stability requirement for this single extension. [1]

Finally we activate the extension in Magento

Once an extension has become stable, we can tag a repository, using the command “git tag”, and use this tag in stead of the @dev flag.

Development SSH Access: Developer Keys

Git repositories are commonly synced using HTTPS and SSH. HTTPS uses a username/password combination, while SSH works with public/private keys. SSH proved more flexible and safe for us.

Each developer has a developer key in Bitbucket that can be configured in his account. This is his public SSH key. It is also possible to have multiple keys, one for each development machine, for example.

An SSH key (private and public) is generated with the command “ssh-keygen” on Linux machines. Bitbucket secures the connection by pairing up the developer key (the public key on Bitbucket) with the user’s private key on the development machine.

We place all developers in a single team, and all projects/repositories have this team as its owner. This way, all developers of the team can access (read/write) all repositories.

Production SSH Access: Deployment Keys

A shop in production has a single user that manages source code updates. This user should only be able to read the repositories from Bitbucket. And it is important to us that this user only has access to exactly those repositories that we want.

Bitbucket, as well as Github, has a construction for this called a deployment key. A deployment key is a public SSH key, just like the developer key, but it’s assigned to specific repositories only, and it is only allowed to read, not write. We can control which shop / user has access to which of our extensions via the Bitbucket interface.

Conclusion

The combination of Git and Bitbucket provides the source code control we need. SSH makes it easy to work with and it gives us the access control we want.