What do you need for CI, Continuous Integration?

• A correct automatic repeatable setup of your project.
• tests, so you can tell automatically if the project works
• configured up to date servers to run those tests
• testing triggered automatically after a change
• feedback flowing to the developers

Okay, that works, with cookiecutter-plone-starter, plone/meta, Ansible, Docker Swarm, GitHub Actions. Most of them open source.

Continuous Delivery:

• Only when CI is green, no test failures.
• You need servers for this
• a CD orchestrator
• persistent data management, including possibly copy of production to test or development

So you not only need to know 100% of the software code, but all on top, maybe 400% more knowledge. No wonder you are burned out! You need to specialise to get this back to having to know only 100%. I like knowing about a lot of things, but it is hard to maintain over years.

We use GitHub. Not open source, so I asked internally if we really want this, as you never now what will happen with commercial companies. But it is there and we use it. With GitLab you could be more open source, but then you would need to run it yourself preferably.

So code is on GitHub. commit to a branch or main: code analysis is run. When we merge to main in certain directories: automatically deploy to testing. Create a tag release: deploy to live environment.

Other implementations are possible, like chat based: add a comment in a PR to ask the CD to deploy to testing.

There are some organisation and security challenges. GitHub.com/plone is open and writeable for a few hundred people. You don't want all of them to be able to change something in the plone.org repo and automatically deploy it live. We can't be this open anymore. So there are restrictions in place.

If you are a sysadmin and are interested in this stuff, please help us, talk to the AI Team (Admin and Infrastructure).
Would be good to get "devcontainers" up and running.

We have this setup for plone.org now, but also for plone.de, 2023.ploneconf.org, plone.nl.

Another thing that we have setup, is for when there is a new Plone backend or Volto version. We update a few version numbers in the repos for the Docker images, and then they get created, tested, and pushed to Docker.

I work at Tekniker. We research and build modern industrial products for lots of sectors.

My talk is about robotics. What is a robot. You may think of a machine in a factory doing repetetive tasks. Or a human-like robot or insect-like cars moving over uneven terrain.

What can a robot learn? They can learn how to move, understand a scene, interact with humans, collaborate with humans and robots. Learn to manipulate objects. Learn to assemble objects, with kinaesthetic learning (you move the robot arm) or mimic learning (you move your arm, robot mimics you). We coordinate the HARTU project that researches this.

Innovate with an eye to the future, exploiting the intermediate results achieved.

[Sorry, hard to summarise, but cool to watch.]

Luistxo: The eibartarrak, gun toting ruffians

Eibartarrak are the people from Eibar. You probably expected to find some Spanish seaside resorts here, as in the propaganda on the conference site. Still, there is #PrettyEibar. Eibar in 1937: Francist soldiers destroyed the whole town, except for the church. So we had to build it all back. It is in progress. But it's the people that matter. Eibar in 1346 a Castilian king told us to build a town. What is the X that appears all over town? It is Saint Andrew's cross, which also comes back in the flag of Scotland. It is a poor geographical area, nothing grows on the slopes, we live in a hole. From the 15th century on, Eibar was making guns. For the government, not personal use. That was my dad's first job, making guns. If you can make guns, you can make bikes, they are tubes of metal after all. Also creating cork screws, staplers, other household materials. Helmholtz electronics. G93: realtime cycling tracking, comes from Eibar.

And CodeSyntax does Plone, fully i18n-ized thanks to Erral. It's the people that matter.

Reminder: at tonight's party, I am the DJ.

Julien Chandelle (jimbiscuit): shortcut pattern bookmark

Extension for Plone. Add shortcuts / bookmarks. Available on Chrome browser.

https://chrome.google.com/webstore/detail/shortcut-patern-bookmark/fneleejokehnmfkbnjfeahieblhaecho?hl=en-US

https://shortcut-pattern-bookmark.affinitic.be/

Philip Bauer: Plone Tagung 2024

March 4-6 2024, followed by community sprint. In Giessen. Most talks are in German, but happy to have English talks. See https://plonetagung.de/

Eric Steele: Unsung Hero

A person stepped up to fill a vital role for Plone. Largely doing so on their own. Who? There are several of you here. Single points of failure for Plone. We lean heavily on you. It is a Plone community problem. It happens everywhere. Cloning would be great, but two Freds would just debate each other to death. We had the 10% Plone Manifesto, where 10% of the time of Plone companies would be for Plone.

We again have Plone TuneUps. One day a month. You get an education and a warm glow. We need not just coders, also project managers, documentation writers, people who do not know Plone. Send me an email or register, link on plone.org.

David Glick: Ideas I don't have time to build

1. Easier input of smart quotes and EM dashes in Volto.
2. TUS uploads (progressive uploads)
3. Blocks import/export as markdown
4. Editor discussions: discuss revisions to documents.
5. ChatGPT: generative Plone text
6. Editor dashboard: show content that you edited recently, content that has not changed in a while.
7. Don't restrict ids. You can't name something 'image', or give it the name that is used as catalog index.
8. collective.exportimport: separate file for each item
9. docker image with unreleased changes from coredev (Erico: there is a nightly image)
10. consistent command line, whether you use docker or something else

Elisabeth and Martin: iMio and OSOR

iMio is finalist of the OSOR awards: Open Source Observatory of the European Commission. iMio serves 404 local initiatives. Please vote for us.

Erico and Kim: Board election

There is an election for the Plone Foundation board. You still have one hour to nominate yourself.

Foundation members will get an email on how they can vote.

See https://plone.org/foundation/meetings/membership/2023-membership-meeting/call-for-nominations-plone-foundation-board-of-directors-2023-2025

If you don't get voted in, please try again next year. It is not a popularity contest.

Kim: Plone Foundation sponsorship

We have a bunch of sponsors, listed on our sites. I did a poor job of updating the list this year. You can also sponsor individually via GitHub. We pay for all kinds of stuff with this money, like some servers.

We also have a Plone service provider list. We want to open up this list for everyone, without needing to pay anything. Contact us, email me.

Fred: Website Team

We have a Website Team in the Foundation? No, we don't. We have teams involved: AI team, Marketing team, PloneConf team, Release team, Volto team, Release managers, etc. But who actually maintains plone.org: Nobody does. Members from the other teams are standing in. plone.org is not a one-off project: worked on it, shipped it, done. No, it is ongoing.

We need a small pool of available developers to work on this, maybe 4-12 hours a month. I like to give training, but we need some experience on a Website Team first. We need a few hands to maintain this site.

Full CI/CD is already there, so that helps. Talk to me, Rikupekka, Erico.

I have created https://github.com/plone/plone.distribution which will end up in Plone 6.1.

With this you can create your own Plone CMS, or:how integrators use 20 years of collective work as the secret weapon to control a market / segment.

I talked about Plone distributions before. Maurits blogged about my talk. I talked about a distribution of Plone specifically meant for Brasil. And after a while I saw that some organisations were actually using it.

The idea is not new. You have Drupal distributions, Joomla templates, Typo3 distributions. For example CiviCRM is a distribution of Plone.

Plone was never very friendly for distributions. Newer Plone versions would come out that made it hard to upgrade the distribution.

The logic to create a new Plone site is currently distributed:

• browser view in CMFPlone
• content in plone.volto, plone.app.contenttypes
• translations in plone.app.locales

So there is no clear contract. How do you create a new site from Python code? No idea, I would copy some codes There is no RESTAPI service. Without such a service, how would you provide a SAAS for Plone?

Still, there are many examples of "distributions" in our family, for example: Quaive, SENAITE, Bika, Portal Modelo, Vindula, Volto, CastleCMS, io-Comune, Classic UI. Reality check: maybe we are not really selling Plone CMS. Plone CMS should not be targeted at the end user, but at integrators.

We need to define what a Plone Distribution is. It is a contract to create a new instance of a Plone Site. It follows conventions about how to create initial content. It provides a Python API and a RESTAPI. Use cases: starting point for a ne CMS project (website, intranet, headless backend, ...), basis for SAAS offering.

plone.distribution is the package that is the basis for this, the factory. Distributions should be first-class citizens in the Plone world. Convert the initial content from plone.volto and plone.app.contenttypes. Cleanup the codebase. It will sit above Products.CMFPlone, so we can use plone.api in the code to make things easier.

You can use it now as an add-on in Plone 6.0.  In 6.1 it will be a core package.

We are not yet another framework, Plone is a CMS. It is good to concentrate, be specific. But I can say: "Plone is a platform, not a CMS." We have solid foundations: permissions, workflow, basis for content types.

Marketing for Plone: focus on a market and segment, not on the common denominator. For some Plone companies Drupal is a competitor, for others Typo3. Plone marketing should target integrators.

By default you will see two distributions when you start the Plone instance: default (Volto) and ClassicUI. You can add your own, and optionally hide the default ones.

Example distributions:

• collective.ploneintranet
• We have portalbrasil.edu/leg/gov/jus as base for public websites in Brazil.
• kitconcept.voltolighttheme. Allows developers to showcase new blocks.
• A to-be-named distribution for personal site / blog. It is scratching my own itch, for ericof.com, and as additional target Maurits, who is blogging right now.

A distribution is not a "policy package". You do not need to have a GenericSetup profile. You can have complex forms, like with collective.plone.intranet.

Next steps.  How to create a front-page in 45 languages? We should think about that. Should we add features in a distribution package? We need to improve content export/import. It works, but I have questions.

We ship this with 6.1. With 6.2 I want to ship with 6 or 7 distributions. It is a seed we plant for integrators to think about.

With production I mean: serving public traffic (or an intranet), highly available, with maintenance and monitoring.

I will talk about dlr.de, about 15 million hits per month, in their own data center.

First availability. We have stacks in two zones, so if one zone goes down, the second zone should still run.

Internet traffic comes in at a load balancer / cache. This points to one of the apps. The apps talk with the database (primary or secondary) and to one of the two search machines (Solr).

We use Docker Swarm mode. Docker swarm used to be a separate project, but now it is part of Docker machine. It provides a good way to manage several apps on different machines. It is containerised: we build an image once, and deploy it on multiple machines. So you do not have a buildout that you need to run a multiple machines before you can run the result. It takes care of process management: restart processes when they fail or run out of memory. Or it can startup the service on a new machine.

It allows for rolling deployments: take down one of the apps, update it, start it, wait till it receives traffic, and then start updating the next app.

With Docker Swarm you can have a declarative infrastructure. We write it, it gets checked into git, others can review it.

How do you design for availability? Avoid single points of failure. What I dislike about this idea, is that it makes failure seem like something that rarely happens. Instead you should plan for downtime: for example a machine may need to restart after getting some package updates. Services should be stateless: the data should be somewhere else (except if the service is the actual database server).

Varnish as proxy cache is a bit trickier. Varnish stores responses, so it is not really stateless. We have two copies of Varnish. This means we need to send purge requests to different places. You could add multiple addresses in the caching control panel, but here it would be two times http://varnish. So we send the purge requests to a purger that sits in front of the two Varnishes.

For databases it also gets tricky: you need a primary database and a secondary that is kept up to date.

What if the two zones cannot talk to each other? On top, maybe the first zone, with the primary database, cannot be reached by the internet. Then you need cluster managers in three different zones, so there are always two left who can decide what to do.

Think about what resource limits you need to enforce.

Now maintenance. Tune backend environment variables, like the Relstorage blob cache size, and ZODB cache size. Tune postgres configuration, especially related to used memory. Configure cron jobs: we use the crazymax/swarm-cronjob image to run these jobs, like backup and packing. With Postgres you also need to do vacuuming. This is done automatically, but especially the blobs table may not get vacuumed often, because not much changes.

Lastly monitoring.The most basic type of information you need, is: is the server down for everyone or just me, use for example Uptime Robot or Uptime Kuma. You can use SigNoz for log aggregation. There are metrics that you can check over time, for example metrics on Traefik can tell you how long requests take, how many requests per minute you get, what percentage of requests are failing.

I like "distributed tracing" better than logs, where you can drill down into details of a request, like how many SQL queries are done.

Also use something like Sentry to get reports/alerts about errors.

With collective.opentelemetry, which I am working on, we get more OpenTelemetry data about Plone and Zope.