Plone 6 frontend and backend automated release and unified changelog
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 44 | |
| Author | ||
| License | CC Attribution 3.0 Germany: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/60210 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language | ||
| Production Place | Namur, Belgium |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
Plone Conference 202230 / 44
10
14
22
23
26
27
40
00:00
Turtle graphicsFront and back endsRevision controlWindows RegistryIntegrated development environmentMathematicsCodeMedical imagingScripting languageType theoryFront and back endsSoftware bugFile formatInformationRepository (publishing)Web pageProjective planeLevel (video gaming)LoginLink (knot theory)Message passingMereology1 (number)Template (C++)WebsiteConfiguration spaceElectric generatorBitDataflowSemantics (computer science)PlanningPhysical lawDemo (music)Product (business)Sheaf (mathematics)OvalCode refactoringSoftware testingDebuggerCloningMultiplication signConnectivity (graph theory)Representational state transferBranch (computer science)Data miningWater vaporHash functionAuthorizationCore dumpBlock (periodic table)Software developerNumberAnalytic continuationElectronic mailing listCASE <Informatik>Right angleSet (mathematics)Instance (computer science)Arithmetic progressionConstraint (mathematics)Web 2.0Variable (mathematics)Computer animation
00:48
Front and back endsProjective planeWeb 2.0Lecture/Conference
01:25
HypermediaDatabaseIntegrated development environmentFront and back endsBlock (periodic table)WebsitePlanningBitArithmetic progressionRevision controlDebuggerMereologyMeeting/InterviewSource code
02:11
Revision controlFront and back endsAlpha (investment)SchwerpunktsystemBlock (periodic table)Stress (mechanics)Cache (computing)Plane (geometry)Data typeGradientConfiguration spaceFront and back endsRevision controlComputer animation
02:41
Revision controlFront and back endsPlane (geometry)Block (periodic table)System callGroup actionParsingCache (computing)DepictionData typeWebsiteComputer configurationCodeComputer iconIndependence (probability theory)MathematicsInformationWeb pageProjective planeComputer animation
03:04
Front and back endsMaxima and minimaIntegrated development environmentVariable (mathematics)Revision controlWindows RegistryOctahedronInformationRevision controlFront and back endsIntegrated development environmentVariable (mathematics)Electronic mailing listWindows RegistryMedical imagingRepresentational state transferComputer animation
04:16
Data typeFront and back endsBitMedical imagingFront and back endsMeeting/InterviewComputer animation
04:44
Data typeLogic gateFront and back endsLemma (mathematics)CodeWebsiteRepository (publishing)Front and back endsBitConstraint (mathematics)Medical imagingLevel (video gaming)WebsiteCASE <Informatik>Analytic continuationComputer animation
05:37
OvalCodeDataflowConstraint (mathematics)Branch (computer science)Software testingMeeting/Interview
06:20
AdditionData typeMach's principleFront and back endsCodeWebsiteConstraint (mathematics)Repository (publishing)OctahedronMathematicsSoftware developerRevision controlFront and back endsMathematicsComputer animation
07:07
Data typePermianSoftware developerMathematicsMessage passingSource codeXMLComputer animation
07:25
Asynchronous Transfer ModeComputer wormFile formatMathematicsInformationMeeting/InterviewComputer animation
08:10
Link (knot theory)Data structureFront and back endsComputer-generated imageryRevision controlMathematicsInformationDifferent (Kate Ryan album)Front and back endsMeeting/InterviewComputer animation
08:26
Plane (geometry)Data typeMathematicsIndependence (probability theory)DemosceneRevision controlLoginComputer animationMeeting/Interview
08:55
Maxima and minimaVenn diagramLink (knot theory)Mathematics1 (number)Front and back endsInformation
09:41
Repository (publishing)Process (computing)Template (C++)Abelian categoryMessage passingFile formatMaxima and minimaTwin primeMathematicsLoginLecture/Conference
10:01
DemosceneRepository (publishing)Computer configurationRevision controlFunction (mathematics)Cohen's kappaDefault (computer science)Data typeConfiguration spaceCountingPattern languageLink (knot theory)Sheaf (mathematics)Gamma functionRegulärer Ausdruck <Textverarbeitung>Category of beingString (computer science)InformationElectronic visual displayParsingComputer fileTemplate (C++)LoginMathematicsComputer animationLecture/ConferenceMeeting/Interview
10:33
Function (mathematics)Independence (probability theory)Computer configurationComputer-generated imageryData typeComputer iconWeb pageBoom (sailing)Clique-widthArrow of timeAreaEmailData Encryption StandardSheaf (mathematics)Greatest elementGroup actionToken ringSoftware testingInformationTemplate (C++)Source codeComputer animation
10:53
Computer wormLink (knot theory)Type theoryHash functionTemplate (C++)
11:13
MathematicsFile formatMessage passingDivisorSoftwareScripting languageVector potentialPhysical systemData typeCodeTask (computing)Software testingMessage passingConnectivity (graph theory)1 (number)Type theoryMultiplication signSoftware bugMereologyGroup actionMathematicsMeeting/InterviewComputer animation
12:00
InfinityRenewal theoryColor managementWeb pageMoment (mathematics)Gamma functionMenu (computing)AerodynamicsProduct (business)MathematicsUniversal product code
12:21
CodeFile formatMeeting/Interview
12:43
Front and back endsRepository (publishing)Revision controlFront and back endsRevision controlMeeting/Interview
13:08
SimulationConfiguration spaceMedical imagingCodeMeeting/Interview
13:29
Data typeInformation privacy1 (number)Computer animation
13:51
Mach's principleLoginComputer animation
14:09
Normed vector spaceAerodynamicsBitMeeting/InterviewComputer animation
14:53
Sheaf (mathematics)WebsiteData typeSoftware testingAdditionFront and back endsPlane (geometry)CloningLink (knot theory)WebsiteFront and back endsMathematicsComputer animationMeeting/Interview
15:10
Block (periodic table)Computer iconIndependence (probability theory)Software testingComputer configurationData typeContext awarenessFront and back endsWebsiteCodeBlock (periodic table)Computer animation
15:29
Physical lawFront and back endsMaxima and minima
16:00
MathematicsFront and back endsWebsiteMereologyScripting languageLink (knot theory)Right angleMeeting/InterviewSource codeXML
16:46
SI-EinheitenRepository (publishing)Shared memoryMeeting/Interview
17:18
Sheaf (mathematics)Software bugCore dumpNumberMeeting/Interview
18:01
Sheaf (mathematics)Commitment schemeNumberBranch (computer science)Electronic mailing listLecture/ConferenceMeeting/Interview
18:42
Degree (graph theory)ComputerRouter (computing)CodeWeb pageData modelWebsiteData typeBlock (periodic table)CountingRevision controlNormed vector spaceTablet computerMenu (computing)Asynchronous Transfer ModeFront and back endsMathematicsCore dumpPersonal identification numberComputer animationLecture/ConferenceMeeting/Interview
19:17
Projective planeLecture/Conference
19:36
Lecture/ConferenceMeeting/Interview
19:52
Block (periodic table)VideoconferencingContent (media)ParsingEmailGroup actionElement (mathematics)Control flowData typeAlpha (investment)Attribute grammarAutomatic differentiationMeeting/InterviewXMLComputer animation
20:12
IRIS-TMeeting/InterviewLecture/Conference
20:42
Turtle graphicsFront and back endsComputer animation
Transcript: English(auto-generated)
00:46
And here is Valentina Ballin. She's a DevOps at All the Web. She will present to you knowledge and experience in frontend backend automated release or CI-CD.
01:01
Thank you Valentina. So hi. I've been working in All the Web in DevOps team since 2017. I was involved in the project the CI-CD automation that we did for the EAA
01:21
projects. And so now I'm going to present a feature that we recently updated that is a little bit a work in progress that shows so this is it. Okay, so you can see this is a plan 6 our demo site.
01:45
It's the control panel and we added this part that allows you to see Let me show you. First of all when the back front end was updated the current version of the front end
02:02
What are the versions that you migrated last time? So for example here you have the version 52 to 54 and all the versions of the add-ons that are used currently in this website. The same thing is on backend as you can see
02:23
this is the date of the update the version of the backend and this when it was released. More than that, so if you see here you have lots and lots of lots of packages So, yeah, this is something very
02:43
long. More than that if you click here, it gives you the release page of the project and here you can see all the changelog. So each release has a small extracted unified changelog that
03:02
extracts information from all the changes that you created in this release. Okay, so how this is this. So how it works? On the backend you have to install the EEA KitKat add-on that saves the version
03:23
and the old version before the upgrade and saves the update in Plone registry on first start and also, you have to configure this is done in our release pipeline backend version environment variable. We only have Docker everywhere. So we
03:45
all the deployments are used only Docker images. On front-end this on first start it uses rest API on initialization to save the front-end information and to extract the list of the
04:05
packages, the don'ts and versions. Russell front-end version is the environment variable that is the same, is configured, is set up, set up on
04:22
release pipeline. So a little bit to describe how continuous delivery works in our Plone 6 backends. So we have two Docker one Docker image that we use as a base for all our EEA backends. So this is if you click on it, you can see that it goes exactly to Plone backend.
04:48
Besides that we put some requirements and constraints. Basically all the add-ons that we want for them to have.
05:01
The next level of the Docker images is the project backend. So in this case is the EEA website backend. We just you can see use the Plone backend that we release and
05:20
besides that add some extra add-ons. Okay. So how the continuous delivery works. We are using Gitflow for our releases. Gitflow I will tell a little bit it's just the idea that you keep the develop branch as the one you use and push all the commits and
05:45
when you're ready to release some production, you create a pull request. There are some checks and tests that are run on pull request and when it's merged in master, it's considered as production. So any merge in master is considered a releasable
06:05
code. So a Python egg is released during Gitflow. Then we do the automatic update at the end of the release flow in constraints. So we update the version. As you can see here
06:21
we have lots of release, automatic release, for example this one. If you look at it it just updates the version of the package. The same is here in the website backend. Here besides the automated release on X, we also have automated release of the Plone backend.
06:43
So this for example is an automated release. Okay, so this is how release works and change log is a little bit interesting because a Python change log is like this.
07:03
We pre-populate it on pull request creation with from change from commit message and user and after that, we allow the user to the developer to change however they want. So this is not
07:22
this is just pre-populated on pull request creation and after that if a developer can add the only thing that we are checking the format for it to be acceptable, we are testing the format. So this one is created, pushed on merge.
07:42
What is happening is that we are using this change log to extract and to create the releases. As you can see exactly the same information that is in change log is saved on each release text. So this is how it looks like. I think all of you know
08:03
GitHub, so this is the thing. So now we have all the Python X with the release text that contained the changes that contain also the user that made them. And we are
08:20
aggregating this information. So a release text for the Plone backend will look a little bit different. First of all, we are for us the most important is add-ons version updates change log, especially the change log of the add-ons that were made by us.
08:43
And what changed and also Plone. How was it upgraded, downgraded? So the idea is for example here we upgraded three versions. So if you click here, it will give you the information. We couldn't put all of this.
09:01
It was too much to put in our release text. So just link and here you have the dependency updates. As you can see this is made by us so we have text. The other ones just go to PyPy to change log. Okay, so also new packages as you can see here and
09:24
some commits that were made on the Plone backend that are not Plone updates, are not automated updates and are not very, just to see who was the user that did the change. So this is how it looks like for backends. For frontends
09:46
we use the same idea, only we don't have two images, only one and we are using auto change log to generate the change log. I don't know if you worked for it. I think you've seen it before. So auto change log is installed by
10:03
running this and you're just giving some commands. The most important is the template. It uses a handlebars template, JavaScript template, to aggregate all the commits and to group them to have something clear. For example here if you were, this is
10:26
the change log, example of a change log. So this one was generated automatically by auto change log. We have a template. I will show you now the template that does this grouping. As you can see it's
10:44
grouped and has all the information that we wanted to add, for example the user and the commit link. Okay. This is the template that we are using for, this is how it looks like. It's basically,
11:01
here you have the text that you want, subject, author, short hash and the link that you wanted and these are the types that we want to be using. I will tell them about here in the semantic commit messages.
11:20
So the idea is for us to start using only semantic commit messages which have this format, type, scope and subject. Type, scope is optional, type is the most important part because it shows you how to group the commits for it to be clearer. So these are the groupings that we decided to work with.
11:46
So breaking changes are the ones that are breaking, causing other components to fail, so they will usually be first all the time. New features are the new features for users that you added, bug fixes is also for the user.
12:04
Enhancement is basically the improvements on code, so refactoring, performance, everything that is making better. Internal changes are if you do style, chore is like no production. Basically no production code change only things that
12:24
improve your code and documentation changes, which is just when you had changed some things. Okay, so this is how our commits should look like using this semantic format.
12:43
And what happens is that when we release a new add-on, vault add-on, we automatically upgrade all the front-end packages on. So we just search in EEA GitHub, check all the front-end because we usually use
13:02
dash front-end at the end, and check packages on and update the version. This release text is generated by using, we have a Docker image that does this part, so everything, all the code you can find in this
13:24
repository, docker git flow, and this is the release it JSON configuration. Release it is a tool that is used to release NPM packages and
13:40
this is the command that we use to generate the release notes. This, for example, just says that you want the ones that are not released and also, we don't want any automated release in our logs because they don't matter for us.
14:07
Okay, so this is the command that we are using. The only add-on that is a little bit special is the Volto EEA KitKat because Volto EEA KitKat has lots of dependencies,
14:24
so we are basically treating it as a front-end. So we are extracting the changelog of the updated add-ons from it. So for example, this is the Volto accordion block, which is an add-on for Volto EEA KitKat, and then we have the next level, which is the front-end changelog.
14:50
So front-end changelog, why don't I have it somewhere clearer? Let me just write it. I forgot to put the link.
15:01
Okay, this is our EEA website front-end. This is how the change release log looks like. So for example, this is the latest 0.54. As you can see here, you have the dependency updates. You can also which
15:21
updated KitKat from 8.22 to 8.23, which updated Volto accordion block. So it's basically one and the other. This is a bigger update, for example, 53. You can see it has lots of updates.
15:42
Okay, so this is how we don't put we also save the plan, Volto add-on, because Volto has the same idea of keeping the changelog in the release.
16:02
So we can also add this as well here in the dependency updates. Okay, and so this is the references. You can have here the link. This is the automated changelog home.
16:21
These are the examples, the two add-ons that you have to add in your Volto for it to work. As I they're kind of big right now. So as I talked with Dallin, if there is interest, we might move this part in the Volto, so it won't be an add-on. And this is the
16:43
scripts that we use to do everything. And these are the back-end and front-end repositories. Okay, so do you have any questions?
17:08
So question Timo. Yeah, first of all very impressive talk and very impressive work. Thanks for for sharing. You should actually like maybe join the release or the CI team.
17:27
Regarding a detail, because I would like to know how you folks handle that. Sometimes you have a bug fix, where you have a ticket number and this bug is fixed in Volto core for instance, right? And you showed that you have this internal section where you have like internal upgrades.
17:45
So how would you handle that if you fix something in Volto core? Do you have like two changelogs, one for the fix and one for the Volto upgrade or only one for the upgrade? How do you handle that?
18:01
No, so changelog is per release. In the changelog, we have a section for the other commits that are not dependency updates. So basically we just put the list of the commits. Let me see if I can find one that has lots of updates
18:22
here. We just put them and we usually also link the ticket number. For example, let me see if there is one internal. This is just a branch. For example, this is for test.
18:41
Here, this is how it looks like. This release, for example, made an internal change. This is a commit that was done by Alin Voina. If you click here, you can see what he changed. Do you have any more questions? It's okay.
19:01
Any other questions? It's a very good question. No, I just want to add more on what Valentina said. So we basically pin also Volto core in this changelog.
19:21
So when you fix the thing into the core, then we upgrade the Volto project. So you will see it here, the upgrade basically, but we have also an internal redmine to track our issues.
19:45
We track also internally and we have the issues. For example, here you can see a downgrade on blown Volto. Downgrades also have the changelog added. So this is...
20:07
Anyone else? Everyone's hungry. Yeah, so I think the launch is served on the main entrance. So thank you and
20:21
see you there. Thank you so much.
20:45
Here's to you, the city of Namur. Thank you.
21:12
Yeah, sure. I just wanted to say hi to all of you.