After the migration of our main app was completed and Datadog was set up on our frontend, we started receiving a lot of errors, warnings, and debug messages on our DD dashboard. At some point, our CTO asked why we were using Dev mode in our production environment.

When we were asked why Dev mode was enabled on production, to be honest, I was not aware of this behavior. What I heard from the team was that they needed it that way to allow debugging their local environments, which didn’t make too much sense when talking about production. After our conversation, I was put in charge of fixing the issue, and what I found was that, by default, it was set to development mode and all the builds were using the same configuration.

The other day, during a daily stand-up, we were discussing how to improve our main website speed. Most of the solutions proposed were related to caching at the software level. My proposal was a bit different, as in the past, when working on Magento infrastructure, I discovered Varnish.

Varnish is a cache software that can be implemented as a reverse proxy. All requests are received first by Varnish, and then, based on its configuration file, the response can be cached or allowed to hit the server behind. The first time Varnish starts, when receiving a request, it validates that there is no cached copy of it. If there is no cached content, it will consider it a miss and will pass the request to the server behind. If the file or content is allowed to be cached, it will save the content in memory, and the next time the same request hits your server, it will return the content immediately.

In the past, we implemented a CDN to reduce bandwidth costs by 80%, and our page speed increased as the CDN cached images closer to the user. As an additional improvement, I proposed transforming the images to make them smaller and using a next-gen format to reduce the size even further. At that point, the business didn’t see the value in this, but a few months later, guess what? I was requested to check how we could improve the listing page speed.

After several iterations on our pipelines, we got to a point where everything is working smoothly, and most of the new improvements are related to optimization, like reducing 1 minute per step by reducing Docker image sizes, or something else that can be considered a real improvement for our flow.

As we are a Super International Team, some of the team members start work earlier than others. This is not an issue for us, as we are more focused on the value we add to the business than counting how much time we spend sitting in front of the computer. The other day during our daily meeting, I overheard a conversation about who was responsible for deploying the feature environments. These envs are removed every day to avoid unexpected costs, and it looked like they were having a hard time deciding who needed to deploy the environment every morning. To make the story short, they came to an agreement and made it work.

When we implemented the Trunk-based deployment flow, our pipeline to prod sped up a lot. This was really cool, but at the same time, we were producing more code than the QA team could handle, preventing us from deploying specific features to production if there was something already in the queue. We kinda solved this by creating feature branch deployments, but the problem was devs merging to QA instead of deploying the testing envs, causing the issue again.