The era when all updates were done by copying modified files via FTP is safely in the past and it is time to use different CI/CD systems. In my case it is Atlassian Bamboo. My current project is the creation of several online stores for one customer based on the Adobe Commerce platform. The infrastructure is provided by Amazon web Services: EC2 instances, RDS Aurora, ElastiCache (Redis), CodeDeploy and Lambda.
Let’s dive into the process. Bamboo collects the actual branches from Bitbucket repositories (configuration, custom modules) and copies them to pure Adobe Commerce, then applies patches (Adobe Commerce and custom). The next step is compiling the dependency injections and compiling the static content. The final step is to build and compress the artifact, which is then placed in the S3 bucket. When you click the “Deploy” button, it will be moved from the S3 bucket to the CodeDeploy agent.
Using AWS CodeDeploy is very convenient because the system can add multiple servers “on demand” when the number of site visitors grows rapidly. But the deployment time for a new version of the e-store is quite long – a competitive deployment takes 3+ minutes.
I started investigating the CodeDeploy agent, which is written in Ruby, and found that some interesting things are happening, for example, it compresses all files into its own archive named bundle.tar (but has .zip headers), and using the RubyZip library also has a limit on the number of files – 65536 (but that’s not so important in this context). The main problem is the “Processing Bamboo artifact files in CodeDeploy” step, since Adobe Commerce has a bunch of files and processing a huge number of files is always a problem.
I decided that if I further compress the platform files into .tar to then extract them during the deployment process with a native unzipper, it would be faster and I wouldn’t have to make any changes to the CodeDeploy utility source code. And it worked, the deployment speed increased and is now around 30 seconds per instance.
Leave a Reply