Recently we hit a problem in our Force Login Magento 2 module: The module was not compatible any more with Magento 2.1 due to a change in a constructor of a Magento base class we extended. This broke the DI configuration which in turn meant the module was not installable in a Magento 2.1 project any more. We were not able to spot this problem early on as our Travis build did only run against the latest Magento version 2.2. Inspired by this blog post of the heidelpay developers, I began to restructure our Travis build.
While working on this prooph components powered API, I realized it would make sense for our mobile client to know when data changed on the server-side without constantly pulling all data from the API and comparing it locally. In a "traditional" application I would have used a checksum mechanism - e.g. creating a checksum of all the data in the datastore - but with an event sourced application this is no longer needed as we can simply rely on the timestamp of the last event happened to know if things have changed.
Last year GitLab introduced the Review Apps feature. Review Apps are app environments that are created dynamically every time you push a new branch up to GitLab. As a bonus point the app environments are automatically deleted when the branch is deleted. Since we moved to using docker for quite a few of our projects I was keen on figuring out how to combine Docker and the GitLab Review Apps functionality as the documentation only mentions NGINX as a way to run Review Apps. As it turns out, it is rather simple to deploy docker containers as a Review App.
In my recent attempt to migrate away from our Jenkins infrastructure to the new GitLab CI Runner infrastructure I ran into a problem: Since we want to use Docker images for the GitLab CI builds I struggled a bit on how pass the authentication information for Satis and GitLab into the docker images. Since the base images - basic PHP setup - should be used for our projects I did not want to share the access credentials in the different base images. Gitlab's secret variables sounded like a good idea but unfortunately they need to be defined for each and every project. Currently we have more than 250 projects in our GitLab instance, configuring secret variables for all the projects would have been a big pain.
Deptrac is a tool recently announced by Sensionlabs. It helps you keep dependencies between the different layers in your architecture under better control by providing insight into the current state of the dependencies and warns you when unwanted dependencies get introduced. To use Deptrac in your application either download the .phar file or add the following dependencies to your Composer configuration:
We recently started experimenting with the GitLab CI Runners as we are looking to replace our "old" Jenkins v1.x set up with something new. And since over the last few weeks we had some issues with the Jenkins GitLab plugin we thought it might a good idea to take a deeper look into the GitLab CI Runners. One the plus side the GitLab CI Runners are configured via a YAML file in a similar fashion as you would configure Travis CI which we use to build our open-source components. Since on Travis we rely a lot on the so-called matrix builds to run the unit tests for different PHP versions I was wondering how we could solve the problem with GitLab CI. At first glance GitLab CI does not have a matrix build command but it comes with a feature called Anchors which kind of act as a template that can be merged in a job configuration.
A little while ago I had to dive deeper into the performance optimized usage of PHPExcel. Our users are uploading files like Excel or CSV with a lot data to process. Initially we used the PHPEXcel instance without any tuning of the default configuration which lead to heavy memory issues on relativly small files. So I had to avoid reading all file content at ones to the buffer (like file_get_contents does).