service/crm.md

@@ -573,6 +573,28 @@ TODO:
 
 -->
 
+CiviCRM's deployment has simplified a bit since the launch of the new
+[donate-neo](service/donate) frontend. We inherited a few of the complexities of
+the original design, in particular the fragility of the coupling
+between frontend and backend through the Redis / ipsec tunnel.
+
+We also inherited the "two single points of failure" design from the
+original implementation, and actually made that worse by removing the
+static frontend.
+
+The upside is that software has been updated to use more upstream,
+shared code, in the form of Django. We plan on [using renovate](https://gitlab.torproject.org/tpo/web/donate-neo/-/issues/46) to
+keep dependencies up to date. Our deployment workflow has improved
+significantly as well, by hooking up the project with containers and
+GitLab CI, although CiviCRM itself has failed to benefit from those
+changes unfortunately.
+
+Next steps include improvements to monitoring and perhaps having a
+proper dev/stage/prod environments, with a fully separate virtual
+server for production.
+
+### Original "donate-paleo" review
+
 The CiviCRM deployment is complex and feels a bit brittle. The
 separation between the CiviCRM backend and the middleware API evolved
 from an initial strict, two-server setup, into the current three-parts
@@ -597,8 +619,8 @@ date. Other components like Apache, Redis, or MariaDB are managed
 through Debian package, and supported by the Debian security team, so
 should be fairly up to date, in terms of security issues.
 
-TODO: clarify which versions of ~~CiviCRM~~, Drupal, Yarn, NVM, PHP,
-Redis, and who knows what else are deployed, and whether it matters.
+Note that this section refers to the *old* architecture, based on a
+custom middleware now called "donate-paleo".
 
 ## Security and risk assessment