BLT End of Life: When Technical Decisions Forget About Users
Executive Summary
Acquia's Build and Launch Tool (BLT) reaches end-of-life on December 31, 2024. As a Technical Account Manager who has helped numerous organizations with their Drupal implementations, I've seen how this transition highlights a common challenge in our industry: technical decisions that sometimes lose sight of user needs. Let's explore what this means for teams and what it tells us about the broader pattern of technical decision-making.
Getting Ready for Life After BLT
I've written documentation for Acquia about replacing common BLT functionalities and provided code examples in a public GitHub repository. Let's be straight about this—this transition isn't as simple as swapping out one tool for another. Some workarounds, particularly around deployment and build processes, can create significant friction for development teams.
If you're using CI/CD tools that rely on blt deploy, you'll need to carefully review and adjust your processes. I've seen teams struggle with this transition, especially when they need to adapt their deployment strategies to work without BLT's streamlined commands.
Why This Matters
The impact of losing BLT goes beyond just changing tools. BLT wasn't just another development tool—it provided crucial benefits that made life easier for teams:
- Simplified deployment processes
- Easy synchronization between cloud and local environments
- Structured configuration management
- Organized settings.php file handling
- Streamlined testing processes
While the Acquia Drupal recommended settings project has picked up many settings-related features, we've lost something critical: straightforward deployment workflows that worked reliably across different environments.
The Real-World Impact
For teams using Acquia Pipelines or Code Studio, the transition away from BLT may not pose significant issues. However, for those relying on CI/CD workflows like GitHub Actions, GitLab pipelines, or Azure Pipelines, deployment becomes more challenging.
Here's the core challenge: Drupal best practices recommend maintaining separate repositories for development and deployment. Your development repository contains composer files, custom code, and configurations, while the Acquia git repository holds the complete installed site with all dependencies. BLT managed this complexity seamlessly. However, the current replacement solutions seem to assume you're working directly in your Acquia repository, which doesn't align with these best practices. This misalignment forces teams to implement workarounds, which can introduce their own potential issues.
For example, in my Acquia blog post, I detailed a workaround using Composer's post-install-cmd script. While this solution works, it introduces a new issue: the script runs on every composer install operation, potentially slowing down routine development tasks. I provided a potential solution by limiting these operations to CI/CD environments only, but this still adds complexity that didn't exist with BLT's streamlined deployment process.
We've Been Here Before
This pattern—where technical evolution creates friction for users—isn't new, particularly in open source. Back in the late 1990s, I was part of discussions about Webmin, a web-based system administration tool. Technical users insisted that direct configuration file editing was the "right way," arguing against GUI tools as too simplistic or limiting. But I saw then what I see now: tools that simplify complex processes serve a vital purpose, especially for teams that need to focus on building rather than maintaining infrastructure.
The early days of Linux on desktop computers tell a similar story. While Windows handled many technical processes automatically, Linux often required end users to perform complex technical operations that should have been simplified. It took distributions like Ubuntu to finally prioritize user experience alongside technical capability.
Are We Learning?
The Drupal community is making progress. We're seeing more initiatives consider user experience in their design, like the Drupal CMS initiative which demonstrates growing awareness of making powerful capabilities more accessible to non-technical users. But we still face challenges—particularly when feature development requires deep technical knowledge.
As technical complexity increases, we risk losing sight of the basic principle: keeping things simple for end users. While we talk about making tools more accessible, our technical decisions sometimes push in the opposite direction, requiring more expertise, more complex workflows, and more resources that not every team has.
What Now?
If you're facing the BLT transition:
- Start planning your approach now—don't wait until December
- Document your current processes before making changes
- Evaluate which deployment strategies will work best for your team
- Consider the impact on your development workflow, particularly around frontend builds
- Reach out to the community when you need help—we're all figuring this out together
The Real Lesson Here
Every technical decision ultimately affects users—whether they're developers, content editors, or site builders. While we shouldn't compromise on technical excellence, we need to remember that the most technically elegant solution isn't always the most practical one.
The BLT transition gives us an opportunity to reflect on how we balance technical advancement with user needs. As we move forward, let's ensure we're not just making things more sophisticated, but also more accessible for teams of all sizes and skill levels.
Have you experienced similar disconnects between technical decisions and practical needs? How is your team handling the BLT transition? Share your experiences in the comments below.
Add new comment