Announcing BLT’s End of Life

[danepowell]

Hello, community! Today I’m writing words I never thought I’d be writing: Acquia is announcing BLT’s End of Life (EOL). We will be handling this in several phases in the coming months, and we wanted to give you a heads up so you can begin planning for how to handle this. Official comms will be coming later today to announce this via the usual channels, but we wanted to post it here on the issue queue first. But, the TLDR:

1. BLT will not be updated to support Drupal 11 – so, if and when you plan to upgrade to Drupal 11, Acquia’s BLT will be a blocker if it’s still in your project. The Drupal 11 release date hasn’t been officially announced yet, but look for it in the second half of the year.
2. Acquia will end support of BLT at the end of 2024 (December 31, 2024) and publicly archive the repository at that time

BLT was released nearly a decade ago to help automate and standardize the way we all build and deploy Drupal sites across the Acquia platform. I’m pleased today that the vast majority of the things BLT used to be “the only real solution for” are now present in Acquia’s products (or other tools).

First and most importantly, BLT will continue to function throughout this year and we will do incremental maintenance (as we have these last several years) to ensure you can continue to upgrade to new versions of Drupal 10. However we will not make updates to BLT to support Drupal 11 when it releases later this year. So, for those of you planning on being early adopters of Drupal 11, we strongly encourage you to begin planning ahead as BLT will block your ability to upgrade.

Second, just because Acquia is EOLing BLT doesn’t mean you necessarily have to stop using it. As long as you’re running Drupal 10, BLT should continue to function and operate (even after we publicly archive the repository).

Third, BLT is and always has been an open source project. It is possible that new maintainers could step forward to keep BLT running into the future!

I know many of you have been long-time users of BLT and we appreciate the many issue reports, pull requests, blog posts, tutorials, and in-person meetups / conversations that have taken place over the years. If any of you feel passionately enough about BLT that you are interested in taking it on as a maintainer, please reach out and let us know.

Finally, I recently posted a blog on dev.acquia.com about how you can successfully build and deploy Drupal at Acquia without BLT. I’d encourage you to check this out if you haven’t seen it already!

A few key features that may require some additional work as you remove BLT. Specifically these are:

• Cloud Hooks – Explore using Cloud Actions on Acquia Cloud Next
• ACSF and Multisite – The Drupal Recommended Settings plugin facilitates the settings capabilities of BLT for multisite.
• SAML – Acquia largely recommends utilizing the SAML Auth module today. Most of our prior work around the “dedicated” SAML capabilities in BLT (and later the BLT SAML Plugin) were related to the complexities surrounding the SimpleSAMLPHPAuth module and PHP library. SAML Auth is much simpler to setup and configure (entirely via Drupal configuration).
• BLT plugins (such as Behat tests) – We recommend exploring composer-based automation for commands contained in BLT plugins (e.g. composer test that will execute the necessary commands for tasks such as automated testing).
• Twig linting – GrumPHP can also be configured to lint Twig. For more information, see https://github.com/phpro/grumphp/blob/v2.x/doc/tasks/twigcs.md

[joegl]

@danepowell Can we have more transparency around this decision? There is always frustration with sunsetting of a often used tool, but with more information it's easier to digest, respect and understand these decisions. In the last 3-4 years I've been working with Acquia platforms we have been consistently directed by Acquia to use the BLT tool. As such, we've built a decent sized library of custom commands on top of it which will have to migrate elsewhere. All this together does not build confidence in using Acquia tools in the future. I am also struggling to find a complete replacement for the customizations we have built on top of BLT, but I'll admit I have not had the time to investigate all the tools we'd need for feature parity in our BLT libraries yet.

[dpagini]

Good session from Drupalcon Pittsburgh on using Robo (which BLT is built on) to do automated workflows...

https://www.youtube.com/watch?v=tVBDSTEiboU

[lpeabody]

@joegl wonder if there is a place we can setup to start identifying and tracking useful tooling that replicates desirable BLT functionality that we'll be losing. For example, the artifact generation is IMO an industry leading feature that is slept on and I want to very much continue to use it. Maybe open a new Discussion thread in this project?

[pixiekat]

Will we be able to run composer on Acquia Cloud? Or should we just run it locally to a separate folder and then commit that straight to the Acquia Git? What is the best practice around that? I looked at the "why you don't need BLT" article but it didn't really mention much about Composer, unless I'm missing it.

[danepowell]

@lpeabody have you tried acli push:artifact instead of BLT's artifact generation? It should produce nearly identical results and is overall easier to use since it automatically detects vendor dependencies to add to the artifact.

I would suggest breaking out discussions about replacing specific features and keep this thread focused on the EOL process itself.

Can we have more transparency around this decision?

I hear you. I'll have more to say on this shortly, let me collect my thoughts.

[lpeabody]

@danepowell I have not but I'll keep that one handy for the future. Thanks.

[joegl]

Good session from Drupalcon Pittsburgh on using Robo (which BLT is built on) to do automated workflows...

https://www.youtube.com/watch?v=tVBDSTEiboU

Thanks @dpagini I was looking at the same presentation earlier. Seems like what we'll have to do.

[danepowell]

I want to chime in not just as an Acquia employee, but as a fellow user and advocate for BLT.

I hear you. It’s not fun to find out that a tool you've relied on is going to be EOL. It creates work for you and for other users like you. It affects the community that's grown around this tool. I don't like seeing that. And I certainly don’t like ending a project that I helped create.

But as someone who uses BLT to maintain several of my own Drupal sites, I firmly believe that this EOL, despite the pain, is the right choice for you, for me, for Acquia, and for the open-source community. I may be wrong, and if that’s the case, I hope that a new maintainer comes forward, and I’ll happily facilitate a transition. But my experience tells me this is for the best.

When I created BLT 10 years ago (before it was even named BLT), I was its staunchest advocate and champion. I built countless sites using it in Acquia Professional Services, and I even advocated for it at Drupal conferences. But if you look at those conference talks, you’ll notice I was advocating for other projects as well, such as the Lightning Distribution and DrupalVM.

Both of those projects are now EOL. Do I think I was wrong to advocate for them? Absolutely not. I had and still have the utmost respect for those projects and their creators. The reason I don’t use DrupalVM (not to pick on Jeff Geerling) has nothing to do with the quality of the project or the community around it. Rather, it’s because tools like DDEV and Lando have matured enough to replace it.

Similarly, I think open-source tools similar to BLT, as well as Acquia products, have matured to the point that for most use cases, BLT simply isn’t the best solution any more. Keep in mind that BLT for Drupal 7 actually predates the Composer 1.0.0 release, and Drush had only existed for a few years at the time. It’s incredible to consider how much Drupal and the PHP community as a whole has matured in that time.

Again, I say this as someone who has migrated a half dozen of my own sites away from BLT and been pleasantly surprised by how much nicer it is to work with native tooling such as Composer and Drush without BLT as an intermediary.

I also hope that this will be good for the community as BLT contributors refocus their efforts on tools like Composer and Drush and help to fill whatever feature gaps might still remain.

As always, I and Acquia will do whatever we can to support this transition and welcome any feedback on how to make it easier. Thanks for reading, and thanks to everyone for your support and contributions over the last 10 years.

[joegl]

@danepowell That was a great write-up, I really appreciate it and completely understand your thoughts on the matter. I have not set up BLT before -- only used and extended what is there, the majority of which are custom Robo commands. I would guess but can't know others are in the same position. dpagini shared a presentation I intend to watch on implementing Robo separately, however the suggestions in the article you put together don't include a replacement for Robo integration/implementation (from what I can tell). If you had suggestions and/or updated the article for that, I think it might help a lot. Thanks for your time and thorough response.

[loopy3025]

Edit: I just saw the request to break out specific questions. I'll move this question there.

https://github.com/acquia/blt/discussions/4749

[JuanVallejosGluky]

@lpeabody have you tried acli push:artifact instead of BLT's artifact generation? It should produce nearly identical results and is overall easier to use since it automatically detects vendor dependencies to add to the artifact.

I would suggest breaking out discussions about replacing specific features and keep this thread focused on the EOL process itself.

Can we have more transparency around this decision?

I hear you. I'll have more to say on this shortly, let me collect my thoughts.

How can I achieve the same behavior as blt artifact:deploy using Acquia CLI?

I want to stop using BLT because it will only be supported until the end of this year. How can I simulate the blt artifact:deploy command with Acquia CLI? When I use acli push:artifact, it always says that the master branch already exists. This behavior was not the same with BLT; with BLT, it deployed directly to the branch. How can I correct this? Thanks!!

[danepowell]

Being unable to push to master is a known issue that we intend to fix: https://github.com/acquia/cli/issues/1758

[eugeneycit]

Hi, @danepowell
Our project uses the blt artifact:deploy command from the blt-travis module to deploy code to the Acquia server. Are there any alternative solutions for deploying code?

[stevenlafl]

There are useful snippets here for artifact creation outside of deployments to Acquia. Is there any plan to let another maintainer take it over outside Acquia? This action further solidifies for me what seemed like an intent to transfer solely to hosting as your business. Please let someone more competent take it over.

[danepowell]

If any of you feel passionately enough about BLT that you are interested in taking it on as a maintainer, please reach out and let us know.