Skip to main content

Composer based deployment - PHP projects

For those who do not have experience with Composer and want to enrich their workflow and make deployment fast and more reliable.

Every PHP developer stumbles upon the Dependency Manager Composer at least once in his career. Probably the majority of us is already working with it on their PHP projects.  

This article is for those who do not have experience with Composer and want to enrich their workflow and make deployment fast and more reliable.     

What is Composer?   

Composer is a dependency manager for PHP.  It allows you to define libraries and system requirements (like PHP version) your project is depending on.   
For a more detailed introduction, visit the official website

Why deployment with Composer?  

We were working in the “traditional” way, developing and debugging on our local dev server, and then coping the ready solution via rsync to the production server of our clients. This did not always work out as expected and led to issues and sometimes even downtimes of the websites, caused by:  

  • System incompatibilities – e.g. different PHP version  
  • Missed files in copy process  
  • Overwrites of "fast" bug fixes on production server    

I was looking for a way to tackle these issues and decrease time and frustration in deploying our solutions on the production servers of our clients.  

As I have been working on many Magento 2 modules, I was already familiar with the Composer and how to use it to implement external modules in various Magento 2 installations. This is why I think that deployment of PHP projects should be done with Composer. And not only Magento 2 modules, but all kinds of reusable projects could make use of Composer.  

For what kind of projects should you use Composer? 

I learned that it’s not required to convert each project into a Composer based project. In my opinion, the Composer can enrich the following types of PHP projects:

  • Plugins and Modules - Magento 2, Typo3 and other CMS Systems that are using Composer to integrate the custom modules within their installation.  
  • Frameworks – when you are building a framework which you want to reuse in other projects.

My message is: "Do not reinvent the wheel!" - You need a framework or Api connector or other functionality. Some Composer package libraries for sure have available. Check out Packagist for example.

How to make a project compatible with Composer?   

To make our modules and solutions compatible with Composer, our workflow required adaptation. We reconsidered the following points: 

  • All our development code isn't publicly accessible.  
  • The solution should not be cost intensive.
  • Current workflow should not be alternated, except the deployment part of course.
  • Deployment should be possible by anyone of the team, in other words; as simple as possible.

These points in mind, I decided for the following setup: 

  • Git Repository on GitHub - for version control 
  • Satis as Composer repository, which I installed on our local server  

The reasons why I decided for this setup are as follows.  

Why include Satis?

To make our project available for Composer, Composer repository was required. And when I was looking for this, Packagist popped up. As their pricing model did not match our needs and would mean high future expenses, this option was discarded. We decided to go for Satis as there are not many other free or open source alternatives. Let's see why:

  • It is open source, so we can run it on our own server, and it's free!
  • Easy to manage (one json file), and can be automated  
  • Works good with Git repositories hosted on GitHub 
  • Gives us full Control on who can see and use our repository  

For GitHub 

A version control system was required, as the Composer repository package requires some kind of versioning. So the end user can require an older version of the package or even custom developments. Github.com was the best option for me personally because:  

  • I already worked with Git repositories and GitHub  
  • I don’t have experience with alternative systems like Bitbucket or svn  
  • It is very easy to create new repositories  
  • It can connect to our ticket system Jira  

How does deployment work with the setup? 

Deployment with this setup works as follows:  

  1. After development is finished, the changes need to be committed to the GitHub Repository.
  2. If it’s a new version release, GitHub gives you the possibility to create a release and give it a version number.
  3. The Satis build command has to be executed, which downloads and zips the newest version to the composer repository. 
  4. As the newest version is now available in the Composer repository, we just need to run the Composer required command on the target server and done.    

We can conclude that the initial setup of a project may take more time, because you have to create a repository on GitHub and connect your project. But the time and security you gain in the deployment makes it worth it. Also, a big gain is the availability of multiple versions of your projects, which increases the range where your project can be applied.  

This entry was written by Rafael our Full stack developer


Also a project like this one?

Drop us a line, we are here to listen to your challenges. Let´s make success.