Quite recently we have updated the deployment of our Magento2 projects to a more flexible and reusable way.
Originally I wanted to create one post to present you our deployment setup, the systems involved, the workflow & process and some code that might be interesting.
While describing this subject I decided to create a series of posts to cover those parts as it was just getting to extensive for one post.

I am planing to cover the following topics in separate posts:

• History and Overview of Magento2 Deployment
• Jenkins Build-Pipeline Setup (building assets, controlling the deployment)
• Releasing to Production (delivering code and assets, managing releases)
• Future Prospect (cloud deployment, artifacts)

 

Then let’s get started with a brief introduction of our former setup for Magento1 and Magento2. You might have a similar solution to this one.

History Magento 1

When we were starting with our first Magento 2 project in June 2016, we ported the workflow we had established for our Magento 1 projects.

Our Magento 1 projects are deployed using capistrano and are using a pull approach, where the server fetches the Magento source-code and the composer dependencies using git and composer.
This approach has some draw backs as we have to have tools installed (git, composer) and we needed a transfer channel back to our gitlab server.

First Magento 2 Deployment

At first, we followed the same approach with the Magento 2 projects.
We applied some minor adjustments to the process, as Magento 2 has some requirement in terms of pre-compilation.

The solution was to generate the static assets and the di on the build server and pushing that to the production server during the deployment.
You should not generate those assets on the production server. The actions performed on the production server should be kept to a minimum, to keep the load down and when thinking about a setup with multiple nodes it just does not seem right to this kind of task on each server.
We ended up with a mixture of a PULL and PUSH deployment, the source-code being pulled by git / composer and the assets being pushed.
We still had the drawbacks from our Magento 1 deployment, as we basically just extended that to fit the needs of the Magento 2 compilation.

Current Magento 2 Deployment

Our goal was to create a pure PUSH deployment where the production server does not need direct access to our git repositories.

So here is an Overview of how our current deployment for Magento 2 projects works:

Jenkins will fetch the source-code using git and composer and update its Magento 2 instance database. It will then generate & package the assets and finally pushes the code and the assests to production server.
To achieve those steps we have setup a Jenkins Pipeline that we will have a look at next.

Summary

This setup comes in handy when any callback (e.g. PULL) is prohibited by a firewall.
Or even a more restrictive environment where a VPN-Tunnel is to be opened which prevents any other network connections to other system except the server.
We were faced with that kind of situations recently, but with using the above mentioned approach we had little effort in terms of adjusting our deployment.

Furthermore following this approach we are flexible where we push to and it is easy to extend and reusable.
In the post “Future Prospect (cloud deployment, artifacts)” we will shed some light on our future plans on how to extend that deployment for different hosting environments.

This was a brief overview of how we got to our current Magento2 Deployment and how it works in general.
The next posts will be about the tool-stack we use and we will share some insights with code samples.

If you have any feedback or questions, as always, feel free to leave a comment or contact us directly.