No matter the project or stack we strive to automate the testing and deployment pipeline as much as possible. Mobile applications are no different, but do come with their own set of challenges between iOS and Android. We are happy to have a fully automated solution for both platforms that pieces together several fastlane tools to achieve an elegant solution.
We can share how all these pieces fit together to create a robust mobile app pipeline.
As our pipelines evolved to support many different environments we felt we needed a bit more automation around our alpha builds. Builds past alpha were generally tagged releases with human written changelogs, but alpha builds were bleeding edge right from our main branch for internal use. We wanted to provide testers with a bit more context on what changed in each build without them needing to go hunt for information.
This is our journey of a bit of automation to plug into Firebase App Distribution to provide automatic changelogs for our builds.
One day our iOS fastlane repository responsible for automatically renewing provisioning profiles and certificates started failing. We utilize match which was affected by this removal causing our provisioning profiles to not renew and thus application builds to fail. The error was suggesting that Apple was removing a parameter we depended on.
The provided entity includes an unknown attribute - 'templateName' is not an attribute on the resource 'profiles' - /data/attributes/templateName
This is our journey of solving it both as a temporary workaround and a long-term solution.
Over the course of a year in 2020, we fully migrated off our Jenkins installation which housed our entire set of pipelines for continuous integration and deployment. This is our journey of creating and open-sourcing a set of actions to grow our GitHub pipelines.
One day we saw an interesting crash that one of our applications was generating a URL so long that Google's static map generation refused to generate it. With a bit of research we discovered lodged in the official documentation that there was a known limit.
Maps Static API URLs are restricted to 16384 characters in size. In practice, you will probably not have need for URLs longer than this, unless you produce complicated maps with a high number of markers and paths.
This led us to discovering that Google had the Encoded Polyline Algorithm Format designed to help pack information in the URL into a dense binary format in plain ASCII text in order to reduce characters. This blog is our journey to writing a little package to accomplish this in PHP.
As our application pipeline elevated into ephemeral GitHub Action containers the Fastlane plugin codenamed "badge" we used was showing some age. It depended on a few native dependencies and took a bit of time to install on our runners. We saw this chance to leverage some exciting new technology and produce an alternative.
As Laravel said goodbye to Laravel Mix and embraced Vite we saw some new exception in our logs as we completed the migration.
Unable to preload CSS for /build/assets/Map-BjJvrIF-.css
Failed to fetch dynamically imported module build/assets/en-c7059b5d.js
We went on a journey to fix this issue and this blog is our findings.
As a project we built evolved with websockets becoming a far more important feature we wanted to move off of a regular implementation of Redis onto a Redis Cluster to scale for larger usage while giving us the safety of failover and redundancy.
As the year clocked into 2023 a package we depended on exceeded a year without a merge with pull requests stacking. At this point we already had a few patches applied locally with patch package, but we decided to fork the package due to our dependency on it.
Here at Sourcetoad, we've been working on migrating our PHP framework—mostly Laravel-based projects—to Amazon Web Services' Elastic Container Service (ECS). As we worked through the process, we were surprised at how scattered around the web good information seemed to be. There certainly was no comprehensive guide to run Laravel applications on ECS in what we would consider an enterprise-grade fashion.
Don't get us wrong: many guides exist, but they appeared to be leaving out important information. Some guides had part of the story, and others had the other part. A person needs to already understand AWS best practices to really know what is left out of each one. We thought it would be interesting to share what we have done in a comprehensive guide. This guide is for people who already have a basic understanding of how to run Laravel in Docker and use ECS. It focuses on the hardening and optimizations we have done.