Things have been pretty quiet on the Simplytest front. But I want to bring a fresh round of changes that will make it an easier project to maintain.
The Simplytest development workflow
In 2021, I spent time helping Adam Bergstein complete the project's modernization off of Drupal 7. We migrated the code from a self-managed virtual server owned by Adam to sponsored hosting by amazee.io on Lagoon.
But, we inadvertently made the project extremely difficult to maintain. Historically the Simplytest has been public as a Drupal distribution. That's just how the project was packaged and used internally. For the Drupal 7 era, this worked out great with existing build system tools. But, with the new setup, it was a bit funky. We needed a Composer build that pulled in the Simplytest code base. We then began to manage two repositories for one system.
simplytest: the main code which provides the functionality of Simplytest on Drupal.org's GitLab instance.
simplytestme/website: the Drupal site scaffolding managed by Composer to create the Drupal site with the Simplytest code deployed on Lagoon.
We wanted to keep some development on Drupal.org because:
- That's where it has been historically
- We could leverage Drupal's issue queues and credits, hopefully fostering contributors.
In the end, this made it harder to maintain. Personally, it made fixing bugs feel like an absolute chore that I couldn't squeeze in.
- Drupal.org's DrupalCI testing infrastructure doesn't support testing profiles, and Drupal.org was still beta testing GitLab CI at the time (it's now generally supported.)
- We couldn't convert the existing
simplytestrepository into something readable by Lagoon or as rewrite it as a normal Drupal build (there are reasons, partly with how Drupal.org assumes a
profileproject should be structured.)
- To test, I had to make a manually triggered workflow GitHub Actions workflow to apply a patch from Drupal.org and run our tests. We had to start any continuous integration manually.
- Deployments were hard. After committing fixes in the
simplytestrepository, you had to run composer update
simplytest/websiterepository 🤮. This was partly automated, thanks to Violinist.
While we worked around some of the difficulties, it was too much work. There were too many menial tasks actually to get to a testable position. And trying to explain this to contributors was horrible.
"Okay, clone this repo. It'll build Drupal. The code base is in
web/profiles/contrib/simplytest. Oh, make sure the Git repository is preserved. Okay, now open an issue on Drupal.org... yeah there it is, not GitHub, where you got the other repository from.
But you know what? It was easier to maintain than the previous iteration. It had and still has its quirks, but it allowed us to support Drupal 9 and Drupal 10 testing, including version constraint checks to help guard against broken builds.
I'm excited to improve upon these features for this community service.
The improved workflow
I proposed to Adam that we ditch the two repository approach and move everything into a single repository, the
simplytest/website repository. One source of truth. One repository that gets deployed. One place to make changes. I created a PR in April that merged the
simplytest repository into the
simplytest/website. I finally merged it today.
It wasn't too hard, actually:
cd simplyest/website git remote add profile [email protected]:project/simplytest.git git merge --allow-unrelated-histories profile/8.x-4.x
This merged in all previous commits and contributor recognition. I wanted to maintain our project's history with this change.
Now all of the code is within
simplytest/website! This will speed up fixes and development velocity for the project. I am working on cleaning up some dependency debt, upgrading the PHP version, and documentation.
The project comes pre-configured to use DDEV for local development. This should make it much easier for contributors, including me, to help fix bugs or troubleshoot the service!
Want more? Sign up for my weekly newsletter