DevOps for GNOME
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 |
| |
| Subtitle |
| |
| Alternative Title |
| |
| Title of Series | ||
| Number of Parts | 55 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 3.0 Unported: 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/54518 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
openSUSE Conference 201834 / 55
8
9
11
15
17
19
20
21
26
28
30
31
32
34
38
39
42
44
45
47
51
52
54
00:00
Process (computing)Multiplication signBitMachine visionSoftware maintenanceLevel (video gaming)MereologyPoint (geometry)WhiteboardSoftware developerNumberComputer animation
00:48
BuildingStability theoryPlanningFeedbackFiber bundleContinuous functionIntegrated development environmentSoftware developerDirection (geometry)Scripting languageFiber bundleObservational studyOrder (biology)Cartesian coordinate systemGame controllerNormal (geometry)Key (cryptography)Stability theorySingle-precision floating-point formatCycle (graph theory)Variable (mathematics)TouchscreenArithmetic meanIntegrated development environmentDampingMoment (mathematics)FeedbackAnalytic continuationInteractive televisionPlanningDifferent (Kate Ryan album)Data storage deviceModule (mathematics)MereologyOpen sourceSoftware developerComputer animation
03:40
BuildingElectronic program guideDifferent (Kate Ryan album)MereologyLevel (video gaming)Right anglePoint (geometry)TrailSource code
04:22
InformationBuildingBroadcast programmingLoginComputing platformIntegrated development environmentModule (mathematics)Modul <Datentyp>Virtual realityVirtual machineInstallation artRevision controlFormal languageInterior (topology)SoftwareCurvaturePoint (geometry)Axiom of choiceComputer animation
04:48
Broadcast programmingLoginComputing platformBuildingModul <Datentyp>Integrated development environmentVirtual machineVirtual realityInstallation artRevision controlFormal languageInterior (topology)Programmable read-only memoryLine (geometry)ImplementationFeedbackMobile appSoftware testingTerm (mathematics)PlanningInflection pointIterationComputer iconGastropod shellBlock (periodic table)Game theorySoftware developerVisual systemCycle (graph theory)PlanningLink (knot theory)INTEGRALRevision controlBuildingPhysical systemFeedbackProjective planeScripting languageGoodness of fitMedical imagingMereologySoftware developerDifferent (Kate Ryan album)ImplementationTable (information)Arithmetic progressionEndliche ModelltheorieLine (geometry)Limit (category theory)Service (economics)Machine visionTerm (mathematics)Interactive televisionView (database)Right angleBasis <Mathematik>Source codeXMLComputer animation
07:09
DisintegrationImplementationCycle (graph theory)DampingType theoryBitINTEGRALAnalytic continuationCollisionDemosceneMachine visionWhiteboardComputer animation
07:56
WhiteboardWorkstation <Musikinstrument>Software developerWhiteboardMereologyGame theoryXMLProgram flowchart
08:15
Level (video gaming)Cartesian coordinate systemSoftware testingScripting languageWhiteboard1 (number)WebsiteComputer animation
09:00
Web pageWebsiteLevel (video gaming)Scripting languageElectric generatorTraffic reportingSource codeJSONXML
09:35
Revision controlRun time (program lifecycle phase)Integrated development environmentAndroid (robot)Touch typingLatent heatControl flowIntegrated development environmentPhysical systemOpen sourceMetropolitan area networkRevision controlRight angleGroup actionCASE <Informatik>Decision theoryComputer animation
11:07
Computing platformRun time (program lifecycle phase)Fiber bundleRepository (publishing)Computer fileCurvatureConfiguration spaceLocal GroupSoftware testingRevision controlPhysical systemGroup actionMenu (computing)Cartesian coordinate systemTelecommunicationSheaf (mathematics)Arc (geometry)Computer animationSource code
12:08
Integrated development environmentRevision controlRun time (program lifecycle phase)MathematicsComputer animation
12:30
Integrated development environmentMathematicsMoment (mathematics)Cycle (graph theory)Virtual machineComputer animation
13:16
Stability theoryFeedbackFiber bundleContinuous functionDemo (music)Gamma functionRun time (program lifecycle phase)Group actionConvex hullModule (mathematics)ArmSpecial unitary groupPointer (computer programming)TouchscreenSoftware repositoryFingerprintNewton's law of universal gravitationRepetitionCurvatureSoftware testingIntegrated development environmentPlanningFiber bundleBranch (computer science)Information securityFeedbackMultiplication signInstallation artBuildingModule (mathematics)MultilaterationCache (computing)Variable (mathematics)Medical imagingComputer animationSource code
15:12
Software testingIntegrated development environmentSource codeGroup actionCurvatureFiber bundleDemo (music)Branch (computer science)Software testingCartesian coordinate systemFiber bundleIntegrated development environmentSoftware developerDifferent (Kate Ryan album)Computer fileLink (knot theory)CASE <Informatik>Information securityDecision theoryMessage passingBitMaizeRight angleGoodness of fitUltraviolet photoelectron spectroscopyMetreControl flowArray data structureGradientWordComputer animation
17:50
Normed vector spaceIntegrated development environmentCurvatureComputer virusFiber bundleDemo (music)RoundingScalable Coherent InterfaceDisintegrationPoint cloudCache (computing)Task (computing)Closed setOpen setComputer fileSpacetimeGroup actionComputer iconInternet forumInformationElectric currentView (database)Context awarenessMenu (computing)Personal digital assistantDrop (liquid)ConsistencyOvalPrototypeMobile appFocus (optics)Error messageVector potentialReliefRing (mathematics)Sheaf (mathematics)Compact spaceInstallation artCycle (graph theory)Normal (geometry)Multiplication signFeedbackWorkstation <Musikinstrument>Line (geometry)Right angleGraph coloringMachine visionTerm (mathematics)Sign (mathematics)Branch (computer science)Task (computing)Element (mathematics)Fiber bundleQuicksortIntelligent NetworkNumberMatching (graph theory)Web 2.0Medical imagingOpen sourcePhysical systemSoftware developerIterationProgram flowchartComputer animation
21:06
CurvatureCycle (graph theory)Cartesian coordinate systemXMLComputer animation
21:28
Videoconferencing
Transcript: English(auto-generated)
00:06
So welcome to DevOps at NOM. I'm Carlos Soriano. I work in our Red Hat, basically as maintainer of Nautilus. But to be honest, I spend a lot of time as well more on the organizational level of NOM
00:20
as part of the board of directors and these kind of things. And recently I have been the point of contact with GitLab because NOM is switching to GitLab with our partnership. I'm also interested quite a bit in the whole experience of developers and users in NOM. So I have been working on kind of like a vision
00:40
with Flapack and GitLab to try to make a full DevOps experience for NOM because before we have been quite bad in keeping with that. So the overview is going to be the first part, which is welcome to hell, which was what we were doing before, how we were building applications on NOM,
01:02
the stability and buildability that we had on NOM, the reproducibility, the planning that we have, the interaction we can design, QA and users, and there is some fun missing there anyway. The feedback cycle that we have. Then for the tools that are fixing this,
01:22
which is Flapack and GitLab, we will see just the basics of GitLab and GitLab CI, and then the Flapack basics. And then finally the most interesting part I think is when you merge both of them, then you create a full DevOps experience with CI and Flapack, Flapack and the reliability, bundles, continuous delivery, and the full new cycle.
01:47
So how we were building NOM before. Have you tried ever to build an application in NOM before? Yeah, yeah, yeah, I can imagine. So we were using something called GHVL.
02:01
GHVL is just like a big script that it has some prefix for installing applications and some environment variables, that's it. That means that half of the things are on the host, and then half of the things we were building from master. And there is no versioning.
02:21
So for example, to give an example, to build Nautilus, it was 80 modules building from master, and it was taking around between four hours and eight hours from scratch. That's a lot for an application in NOM. And you can imagine when you are building
02:41
80 modules from master, that some of them are not even controlled by NOM, it's gonna break, it's gonna break. So what we were doing for fixing this problem before. Good luck. Literally nothing. We had nothing before.
03:01
And this is really about experience. You can imagine for new contributors and for developers, even for people, distributors, designers, this is insane. So for the possibility, basically we had different environment for developers, designers, QA users, because developers were using maybe a very updated
03:21
store like Fedora, things like this, the latest Fedora, but maybe designers are not. They are using maybe Open Source or Arch or whatever. The same for QA and users. So the problem is that everyone was in its own environment which makes things quite difficult. I need to keep time.
03:41
Let me, okay. Because it's my first short talk. I usually do long talks, so I don't want to keep very long. So yeah, I think most of us have seen in the last part in the users that when they come to us and try to file a report, we say, oh, it works for me, right? This is very typical. And this is because they are using
04:00
different environments, right? And here there is something interesting. This was the first, like the guide we have for newcomers. And can you see here? I will show you directly on the, here. Can you see here in big?
04:21
It is strongly recommended to use Fedora 25. That at that point was the latest. And that's it. We only supported Fedora. Very politically correct, right? For GNOME. And I remember Dimstar, I don't know his, okay, you. Yeah, you were not pleased with this. And you were like, come on. This is not motivating. And I agree.
04:41
This was not a good experience. And it's really bad. But we had no other choice. And I'm happy that now we have the choice. Then also, this was inside the above experience, not in Flatpak, but still.
05:03
We were doing project planning just in the wiki. It was just a table with links to bugs. Nobody was updating it. There is no integration. And you couldn't query things like the whole short ambition for GNOME or long ambition or things like this, which is also very bad for distributors like OpenTools.
05:20
So ideally, what we will have for the integration between designers, QA, and users is that, for example, designers have mockups, and they iterate on them. And they can, they should be able to try work in progress, like in a branch or something. But they are designers, so you cannot make them build Nautilus, AT modules that probably they are going to fail anyway.
05:43
They also usually want to see different versions. For example, the development version alongside the system installation. For designers, this is very good because they can see the difference here, if it works, if it doesn't work. And they can iterate on the feedback. And of course, they are either later or non-technical.
06:01
So you cannot give them just a script and good luck. And this is the kind of thing we have before, which is Baxila. So they attach some image or something. There is no inline support for images. There is no way to try out new things in here, not even the implementation for the things they do. So yeah, it was quite bad.
06:23
So the problem is that everyone was following the same path as the developers, and that's not ideal, right? Ideally, we have early feedback from designers, from users, from QA, that they can try these things just with one click, everything visual, no command line, and that this path is optimized
06:41
for users, QA, respectively, or designers. Okay, let's go to the second part. So this is what we have until now, quite bad, I think. To be honest, I cannot imagine now how we have lived in there for so long. I don't know, I don't know how we did it.
07:01
But now, I will explain the tools that solve these issues, Flappa and GitLab. So just the very basics of GitLab. It's a tool that it was made from scratch for a type of experience. So that means everything is integrated. What we have before is Baxila, C-Git, and GitBuild, and everything, and now everything's integrated on the same tool.
07:22
It's very similar to GitHub, if you know GitHub, but it's a bit more powerful, and it's free software. As I said, everything's integrated. The whole thing from idea, to design, to implementation, to continuous integration, QA, continuous delivery, and again, and the full cycle of the post.
07:40
So that's very good for us. And it has support for non-technical teams. And this one is very important because nothing makes me more happy than to see this, which is right now in the normal GitLab, we have all our teams using the same tool, design, engagement, Ubuntu, Purism, Fedora, translation, developer portal.
08:01
Even the board of directors are using this tool, so everyone is in the same. You can use labels and things like this. The UI is quite nice. But okay, the most important part on the technical, let's go to the technical part again, is the CI is similar to Travis, if you know it. It has pipelines. For example, you can have pipelines on stages.
08:22
So for example, you can have build, test, deployment, and review. There are a few of them. You can have artifacts, which is a way to put from the container to the public, to policy something. And there are schedules.
08:40
So for example, you can do something like, every Sunday, I will deploy my application to the users, so they will use an update, and you don't have to do anything else. So let's see how is the CI that we do. No, sorry, this is just a small example. So basically, how the GitLab CI works is that you choose a Docker CI image,
09:03
and then you have the stages. For example, test, and you just run a script. For example, Hugo, which is a generator of static websites. And then you deploy in the pages stage, doing the same, but then you put some artifacts, which is the public folder from the website.
09:23
And that's it. It's very simple. This generates a static website in some link. So I think it's quite nice. It's quite powerful, the GitLab CI. And now Flatpak. How much of you know about Flatpak?
09:42
You know? Okay, most of you, yeah. So probably you know already the basics, but I will do very fast this one. Basically, it uses container technologies, like OS3. It's unboxed. That means, and it's unboxed by default.
10:00
If you want, you cannot opt out of that. You can punch holes or make use of portals, which is similar to Android intent. But yeah, it's a sandbox. You cannot just remove the sandbox system. It has a consistent environment, which I guess you can start imagining how this fix things that we have talked in before,
10:21
because everyone is going to use the same environment. It doesn't depend on the host, basically like a container, right? So it doesn't touch the user installation. It's also version, so you can have SDKs like an Android, for example. So you target that specific version, and it's forward compatible.
10:40
So even if you are using a very new distro with a very old application, that's gonna keep working. There is nothing that is gonna break it. And because of all of that, it's cross-distribution. So finally with this, we can say to Deepstar that he doesn't have to worry about newcomers to GNOME, because now they can use open source and contribute to GNOME freely.
11:03
So just a very basic on how you create a Flatpak manifest, which is what defines your application. I will show you now a Nautilus Flatpak. It's very simple.
11:20
You have the first section, this one. Can you see well there? Yeah, it's fine. The first section is just describing the application name, then the target, like it's using master, and the SDK, which is GNOME. There are Caddy, there are Electron, there are others. And we put some tags.
11:42
And then we describe the actual application, the dependencies that are not in the SDK. Nautilus has actually not many. Exif, Gxif, which is a wrapper, or the first one. Tracker, Nomaduar, and Nautilus. And that's it. This is how you build Nautilus. It's as simple as that.
12:01
You do Flatpak, build there, build this, done. And housing of this is that we have go from the four hours,
12:22
within four hours, eight hours, I said before, to six minutes. Now anyone can go to Nautilus, for example. You open Nautilus, usually Nautilus. In six minutes you have Nautilus there running. And it's gonna work because it's using this environment that is isolated from the host. I think that's pretty good.
12:40
That's a really big change from what we have before. And I'm very happy that we have that. So again, since it's a possible as well and the environment is consistent, we don't have any issues that we talked before, like the versioning or breaking because some other module master is broken or something like this.
13:03
And now, okay, I have five minutes. Yeah, it's enough, I think. The last part, I think is the most interesting, is when you put Flatpak and GitLab together, basically using the CI because the CI is the year, the thing that connects Flatpak with GitLab in a way to create this DevOps cycle.
13:23
So let's see how we do CI for Flatpak and Nautilus. Well, Nautilus and the whole of them, actually. So it's quite easy. We have an image that we created. It's just, I think, a very, very minimal federal image
13:42
which has the Flatpak SDK installed. So if you have the SDK installed, you don't need to download it every time. We have some variables just for building. And then what we do is flap a builder, and we say to stop on the Nautilus module.
14:02
So we build all the dependencies. Then, yeah, we stop. Then we build the actual Nautilus. We have to do this because we are doing this in branches. So for example, when you create a merge request on Nautilus, now you will have the CI triggering
14:23
and then it will build whatever is in there. To do that, you have to build whatever the GitLab CI is downloading there, not the actual upstream Nautilus, right? So we stop on Nautilus, then we build what GitLab CI has inside. But everything is done inside the Flatpak environment. Then we install, and then we run the test.
14:46
And finally, we create a bundle that we will speak about this later. But it's quite simple. Then we have some artifacts, which is what we showed to the wall and it's basically the bundle that we'll see later. What is that?
15:00
Some logs, and we say that it expires after 30 days. And then we have some cache. So every build is gonna keep this cache. So basically how it looks like is that, for example, you go to pipelines, pipelines,
15:38
and here you can see all the CI for every branch that we have.
15:41
So you create a merge request and the CI is triggered. That's quite good, because now what do we have? We have pre-merge, build test, and runtime test. We no longer have the issue about just putting to master something and boom, GNOME now breaks and nobody can build GNOME anymore and things like this because we had these issues before.
16:02
Now everything that goes on master is passed through the CI. And since the environment is the same as the developers are using, if it's passed the CI, it's gonna be buildable for any developer as well. So we already fixed those issues that we told before. And as I said before, it's quite fast, from four hours to three minutes.
16:23
Now the second part, which for me is the most interesting and I think is where actually Flatpak makes a difference here, Flatpak together with GitLab, is bundles. So with Flatpak you can create a containerized bundle, like an application you can download, like in Matintos, right? And then with that you can install that and run it.
16:43
So what we do, for example here, this is a merge request. I created a branch in Nautilus. I created just for this talk. I modified, I will show it to you, here. Can you see the so hidden files here?
17:00
I modified this label and I put something in there. I create the branch, I create the merge request, and now here the CI triggers and creates, makes the test, the build, and then creates this bundle. And using GitLab review apps, which is something for making deployments, we go to the continuous delivery, which is exposing the Flatpak bundle.
17:23
And it's in this link. So this is just a regular merge request. So we click here. It's downloading here.
17:43
Double-click Nautilus the Flatpak. Install.
18:00
Launch. Done. This is Nautilus master. This is Nautilus from there, from the merge request. And you can see it here. Hello, open source conference. This is amazing. Now designers doesn't need to build anything. They can just go there and install whatever we have done. We solved the problem.
18:21
We finally have like a DevOps experience together, you know. So finally, so what we have here is that we generate
18:41
installable bundle per merge request. We have parallel installation. So designers can see, so you can see the system installation on the left, the developer installation on the right. And they can make difference between them.
19:01
They can provide any, you know, feedback that they have. And now the last thing is how this goes together. Now you have more or less the big overview. But basically, I will show you a real example. Recently we had,
19:22
well now we fixed also, we filled up this short-term vision and long-term vision of GNOME. Now we are using these epic labels, stretch labels to say like what are the short-term vision of GNOME, the big task. And one of them is the action bar. We make a proposal of, and I don't have water, okay, anyway.
19:41
To make an action bar. So thanks to the Flatpak and GitLab, we had around six designers that we never seen before in GNOME. Just random users, random designers from the world that came just to help us with the feedback because they could install this quite easily.
20:00
So we propose something. Finally we have, oh, thank you very much. Finally we have inline support for images. And then with, what I did here is that with the signs, the designer puts some mockup. And then I create a web branch. I create a, sorry, a web request.
20:22
The designer clicks, install. No, I don't like it. Let's do another mockup. You can see here that there are a lot of mockups, a lot of designers, a lot of user providing feedback on mockups. So he was doing another mockup. I created a new request. And again, and again, and again,
20:40
and the iteration was so easy because they just have to install anything. And then finally the last one, this one, and we merge it. And that's it. And it's the first time that really the designers have been happy to, hey, I can't just go here and try things barely early on the cycle. So yeah, the last one.
21:02
The Bobs. We achieve it. And this is for GNOME. But actually you can do it for any application. And I think it's very helpful to have this whole cycle of Flapper plus GitLab. Questions?
21:21
Okay. Thank you very much.