Modern Continuous Delivery for Python Developers
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 |
| |
| Title of Series | ||
| Number of Parts | 118 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 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 and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/44811 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
EuroPython 201960 / 118
2
7
8
15
20
30
33
36
39
40
45
49
51
55
57
58
63
64
66
68
69
71
74
77
78
80
82
96
98
105
107
108
110
113
115
00:00
Software developerContinuous functionModemCloud computingGoogolSoftwareCodierung <Programmierung>StatisticsSoftware engineeringBuildingSoftware testingBroadcast programmingRevision controlControl flowCodeDemosceneLaptopSlide ruleUniform resource locatorAnalytic continuationSet (mathematics)CodeProduct (business)Process (computing)Cartesian coordinate systemBasis <Mathematik>SurgerySoftware developerScaling (geometry)Presentation of a groupTerm (mathematics)Proper mapINTEGRALAxiom of choicePoint (geometry)Software engineeringMachine codeCloud computingConstructor (object-oriented programming)Revision controlBridging (networking)Software testingBoss CorporationBitHypercubeMetropolitan area networkLogic gateSoftwareHydraulic jumpOpen sourceDemo (music)Projective planeOnline helpCalculationMathematical analysisDemoscene1 (number)FreewareScheduling (computing)LoginPoint cloudStress (mechanics)Structural loadArithmetic meanMachine visionMultiplication signMultiplicationSmoothingControl flowLecture/Conference
09:14
Open setComputing platformDemosceneSharewareComputing platformMachine visionShift operatorComputer animation
10:09
DemosceneService (economics)Core dumpProjective planeHTTP cookieCodeMereologySoftware testingNamespaceRepository (publishing)Musical ensembleMoment (mathematics)Demo (music)Computer animationXML
12:25
Focus (optics)Demo (music)Projective planeComputer animation
13:15
Correlation and dependenceControl flowHill differential equationSineDemosceneProcedural programmingProcess (computing)Service (economics)Commitment schemeInstance (computer science)XML
14:00
Control flowBuildingService (economics)Arithmetic meanINTEGRALObject-oriented programmingOperator (mathematics)XMLSource code
14:40
DisintegrationError messageMotion blurMaxima and minimaMenu (computing)Normed vector spaceDemo (music)Object (grammar)Thread (computing)Data compressionTrailBranch (computer science)Token ringToken ringMachine visionUniform resource locatorSource codeXML
15:15
Compilation albumThomas KuhnConic sectionDemo (music)Token ringThread (computing)Data compressionObject (grammar)Branch (computer science)TrailDisintegrationPhysical systemIRIS-TDensity functional theoryProcess (computing)Coma BerenicesWeightContinuous functionNamespaceService (economics)INTEGRALCartesian coordinate systemMedical imagingGoodness of fitCommitment schemeHTTP cookieSingle-precision floating-point formatPresentation of a groupSoftware testingSource codeXMLProgram flowchartComputer animation
16:30
Basis <Mathematik>DemosceneCartesian coordinate systemData structureCodeSoftware testingLocal ringNetwork topologyConfiguration spaceComputer fileComputer animation
17:25
Integrated development environmentLoginComputer fileDirectory serviceReading (process)Default (computer science)ExplosionInformation securityPressureDemosceneContinuous functionLine (geometry)InformationTotal S.A.CodeSoftware testingDemo (music)Form (programming)Computing platformExecution unitModule (mathematics)Binary decision diagramParsingData typeMusical ensembleMultilaterationNeuroinformatikMessage passingSoftware testingLocal ringComputer animationSource code
18:19
DemosceneIntegrated development environmentDivisorNetwork topologyDependent and independent variablesDifferent (Kate Ryan album)Integrated development environmentCartesian coordinate systemDivisorMobile appLogicComputer animation
19:26
InfinityINTEGRALComputer animation
20:05
Integrated development environmentDivisorNetwork topologyStandard deviationTwin primeLoginPressure12 (number)Normed vector spaceCartesian coordinate systemSoftware developerLocal ringWeb 2.0EncryptionUnit testingProper mapInstallation artSoftwareService (economics)Configuration spaceIntegrated development environmentBuildingComputer fileDecision theoryRepository (publishing)SubsetLogicServer (computing)Dependent and independent variablesCartesian coordinate systemStandard deviationWritingMereologyPublic-key cryptographyOnline helpHuman migrationEmailSoftware testingCodeMaizeElement (mathematics)Virtual machineIndependence (probability theory)Projective planeHacker (term)Vulnerability (computing)
24:47
Software testingTemplate (C++)INTEGRALMedical imagingMathematicsProduct (business)Installation artBranch (computer science)Term (mathematics)Integrated development environmentComputer animation
26:43
Continuous functionDisintegrationINTEGRALProcess (computing)Medical imagingShift operatorLocal ringDemo (music)Process (computing)INTEGRALDatabaseMathematicsGodLink (knot theory)BitVirtual machineSoftware testingWindows RegistryVideo game consoleBuildingSingle-precision floating-point formatXML
28:46
DemosceneExecution unitMedical imagingProduct (business)Computer animation
29:24
LoginCartesian coordinate systemHuman migrationMetropolitan area networkGradientLink (knot theory)Data management
30:27
Web pageExecution unitDefault (computer science)DemosceneWeb pageCartesian coordinate systemSystem administratorLink (knot theory)Web 2.0Computer fileServer (computing)Computer animation
31:31
IterationOpen sourceInformation securitySoftware testingCodeOpen setSoftwareInformation securityLine (geometry)FreewareProjective planeDisk read-and-write headComputer programWritingSingle-precision floating-point formatReal numberVulnerability (computing)Web pageCartesian coordinate systemSource codeTest-driven developmentOpen sourceComputer animation
33:53
SoftwareInflection pointComplex (psychology)Population densityRule of inferenceBeat (acoustics)CurvatureError messageImplementationBeat (acoustics)Analytic continuationError messageRule of inferenceImplementationComplex (psychology)QR codeGoodness of fitDemo (music)HTTP cookieSparse matrixMultiplication signCountingCurvatureProduct (business)Computer animation
36:20
SoftwareConfiguration spaceProduct (business)Metropolitan area networkSlide ruleBuildingIntegrated development environmentProcedural programmingInformation securityOperator (mathematics)Mobile appCombinational logicInformationInstance (computer science)Medical imagingCoprocessorPoint (geometry)Single-precision floating-point formatBitCircleDifferent (Kate Ryan album)CodeBefehlsprozessorLocal ringWater vaporBootstrap aggregatingOnline helpUniform resource locatorTemplate (C++)Expert systemFormal languageGoodness of fitVirtual machinePoint cloudOpen setSoftware testingMereologyArithmetic meanMultiplication signCASE <Informatik>ConsistencyRepository (publishing)Public-key cryptographyType theoryComputer fileKey (cryptography)HTTP cookieCubeComputer clusterRight angleBasis <Mathematik>Service (economics)Computer animationLecture/Conference
Transcript: English(auto-generated)
00:03
Thank you for the flowers. If you want to follow the slides on your notebook, there is this URL, tinyurl.com slash modern cd. And this will kind of move you forward automatically as we move forward here.
00:22
All right, yeah. Have you ever compared other professions with software development, really? I mean, I'm talking about construction, plumbers, electricians, and doctors.
00:40
So what I mean is, do doctors wash their hands before they do a surgery on you? Do you want that? Or would you pay extra if they do? Electricians today add a grounding face to every installation, or just the ones that are paid better.
01:01
Plumbers, when they fix a toilet, when they mount a toilet, they usually use a rubber seal for every toilet, don't they? And then in construction, I mean, bridges, this is the example. Usually, there is an architect that does the bridge.
01:22
And he hires or she hires structural engineers that do stress analysis and calculations so that that really works out and doesn't break. So imagine the Golden Gate Bridge breaking down with a lot of traffic on it. I mean, it's horrible.
01:40
So what about software development? Do we do that? So does every one of us write tests? I mean, seriously, who writes tests for every piece of code? Well, I mean, what do you think? That's fine. Everything, every valuable piece of code.
02:01
If you think the code is not worth anything, you probably don't need. But who does it? I mean, who does it really? Yeah, more than I would have guessed. And well, the modern about the continuous delivery
02:20
here in this talk. Let me just get my beamer on. Does this show? So the modern is actually less modern than you would think. It's more about how should you work today so that it's
02:43
actually working out for tomorrow. And nothing bad happens like bridges that break down or so. So it's not only about Kubernetes and hyper technologies. And so all the technologies you'll probably notice.
03:02
But keep in mind that the actual point of this presentation, of this talk, is that you should do your software properly. My name is Peter Bittner. I'm a developer of people, companies, and code. I run painless software.
03:20
And for my day job, I'm a DevOps engineer at Vision AG in Zurich. And I do a couple of open source or free software projects, really. So there is a choice of them here on the slide. And yes, well, I love to help everyone run their software
03:47
smoothly. And this is also what is continuous delivery about. So let's go to the basics. This is the definition. It's a set of practices and principles in software engineering aimed at building, testing,
04:00
and releasing software safely, faster, more frequently, and in a sustainable way. And there's more to it. It is the goal of continuous delivery to put the release schedules out of the hands of IT and into the hands of business.
04:21
So the one that pays you, I mean, I'm not talking about your boss, but your customer, the feature sponsors, they are meant to press the release button. And you are meant to prepare everything for it. And there are some other terms that are, well,
04:40
used confusingly in a similar way that I want to mention. So especially continuous deployment. So this is a popular term today used by Amazon, GitLab. Atlassian, unfortunately in the wrong way, I believe, because continuous delivery is actually a concept.
05:06
And the other two are techniques. So you use a technique of integration and deployment within the concept of continuous delivery. And actually, automatically releasing
05:22
is much, much easier than giving control out of your hands. Think about that. And if you want to read more, it's Jess Humble who wrote the book in 2010 about it. Yeah, and what's the modern then about here? Specifically, it's about what everyone does today.
05:42
It's about, come on. Probably batteries are empty. It's about immutable infrastructure that's containers. It's about container orchestration that's Kubernetes, OpenShift, Docker Swarm, and so on. It's about version control automation.
06:00
So all things you know already, you may also use on a day-to-day basis. This is about CI CD pipelines. And it's about cloud native application, which are applications that are resilient on scale. So resilient means when they fall over, they stand up again by themselves.
06:21
So after a tech, for example. And when there is a heavy load, you can scale them. You can launch multiple copies of them, and they will share the load. And there is more about modern also, another aspect. The modern world is so complex that we need help.
06:42
So there are various offerings that help us with getting our software in a cloud. Yeah, cloud services, like on AWS, by Google, by Microsoft Asia. There's OpenShift, of course. So there's all the Kubernetes stack.
07:03
And yeah, and not everything is a choice here. So some is a lock-in. I mean, the borders are blurred. But there's a bit of a problem with being locked in. And we are locked in when we use an API,
07:21
an appropriatory API. So we are locked in when we use something that is only available on AWS, for example. And why is this a problem? Because it doesn't allow us to move fast. So imagine one day you find out, well, they raise their prices, and you don't like to pay the higher price tag.
07:41
I mean, OK, they're best in town. But yeah, let's switch over to Asia or Google Cloud. They have a similar thing. How long will it take you? It's probably a project of weeks and months. But actually, it should take you, if you do it right, a couple of, what I'm probably not saying minutes,
08:01
but maybe hours. And that's it. So that should be. So this is today's situation. So do we have a choice? Can we change this? And I would say yes. And there is a very boring answer to this.
08:23
Some people may know him. This is Uncle Bob. He's telling for years that we should do clean code. So we should do proper software development. And I would add to that, we should deploy from commit one
08:40
to production. Because that's where your time is missing in the end before you're releasing to production. You know, it's so scary to be back. All right. So let's jump directly in the demo. So I want to show you how this can be done.
09:03
So I actually showed a demo with two things. This is on, I'm not showing here. This is on, let me actually do the,
09:24
I need to make this simpler. Otherwise, I can't go fast. Where is it? I'm sorry about that. I need to make a mirror. I hope that works out.
09:46
OK. So I'll show a deployment on Apui. I mean, this is just an OpenShift platform that I run, that Vision runs, the company I work for.
10:01
And this is just OpenShift. So what I've already prepared is I have kind of made this a free trial and created two projects, three projects actually. And I'm going to use, oh, no, that was the wrong button.
10:22
I'm going to use a cookie cutter for generating a project, a Django project. So I'm going to copy this code here to get started with cookie cutter. And then, yeah, here we are.
10:42
So, yeah, I've downloaded this already. So who is me? That's me. And that's, yeah, Django. And this is the Euro-Python demo.
11:02
And a demo for a talk, US delivery. Sorry, I'm not so fast like other people.
11:23
And we're going to do that with GitLab.com. I have prepared a namespace there, GitLab CI, deployed to Apuja for the moment because that's supported. And then I will use Django and Postgres. We run all the linting and test for Python 3.07,
11:43
behave BDD, and add some sentry thing. All right, voila. So this has been created. If you don't see this, this is the important part. So this is what happened, Euro-Python demo.
12:00
And yes, really, there is a repository already initialized. And git remote minus v. And it's there as promised. So it says I can create the project here. Let's create it here. Did that work out?
12:21
Well, it's probably on the wrong. Well, let's do it like this. GitLab, Apuja. And yeah, we need to create that one. So create a new project.
12:41
Oh, it's actually Euro-Python demo. Yeah, it was the demo for talk delivery.
13:00
So everyone knows about it, make it public so everyone can see what we're doing. Yeah, so that's it. So we know that we can, we don't need to look up what the instructions were because we know when we push there, that should work out. Right?
13:24
OK, let's take a look. Yeah, that's cool. It worked out. So there's the first commit. And yeah, we need to do some setup of the Apuja instance, so the OpenShift cluster.
13:40
So we have three, we have actually three accounts here. The CI process is explained here down here. And we need to run those setup procedures that are described concisely here. And the README, there's a service account
14:01
that we have created. Everyone who does Kubernetes knows, or OpenShift knows what this means. And then we give them the permissions. And oops, sorry, wrong button.
14:20
And yeah, now we need the token here. And we need this token because we do the Kubernetes integration. This is nice. Where is it? Operations, Kubernetes.
14:42
And there is no cluster configured yet, so we add an existing one. We add, this is the URL of Apuja. And there is the service token. This is managed by Vision, so we don't need to manage this with GitLab.
15:01
Yeah, OK, are we done? Let's check. Well, last step, we need to provide access to the service account from the other namespaces.
15:25
So we have this. This was the last one was for the development namespace, and now we have before we had the integration namespace. So yeah, and that's it. Let's check what happened in the meantime.
15:41
So we have a pipeline running on GitLab that was configured. And it looks like this. It has the checks. So this is the linting. And we run tests, the one that we configured. And then the image will be built,
16:03
so the Django application will be built into an application image, and it will be deployed later. So this all goes directly with a single commit. Of course, we have prepared this, and you can do this too, or you can use something like the cookie cutter that is there.
16:20
Good. So let's go back to the presentation, actually. Oh, we don't need that. Yeah. So let's talk about what is in there. Oh, that's what I wanted to show, actually.
16:42
So there is this tree structure here. So I can show this what the structure actually is. So we have the application here, the application code. So this is a typical Django application. And then we have the deployment stuff in a single folder.
17:01
These are YAML files. This is Kubernetes, OpenShift-y Kubernetes YAML files. And then we have the Docker Compose for local development. We have the tests for local development, and also, of course, for the pipeline.
17:20
And we have for local development, we have talks at talks configuration. So we have a few things here running. You can, as usual, you can use that. What is it? Let's do the safety. That looks nice. So the same thing we run. So actually, when we run just talks, we run everything.
17:42
So the same thing that runs on here runs, well, the same thing that runs here, runs identically on my local computer. So I'm not doing anything special.
18:01
And I'll show you why and why this is important. And of course, it behaves the same way it will behave on the pipeline. So all of the tests, the linting passed. And there was nothing built yet, but we'll see that later.
18:22
So let's take a look at what that is all about. So it's actually, I made this to set up in, what I used are kind of responsibility layers. So it kind of looks like the boat here for a reason. So there is a layer for the application logic.
18:42
There is one for development. There is one that is concerned just about deployment. So this is actual deployment to some environments. And then there is the automation stuff, so the pipeline mainly. So in detail, what is it about?
19:02
So what you should care about is that when you do it in a modern way, you just do it for one environment. Don't think in environments like this was traditionally done. Do think in 12-factor apps, so you read everything out from the environment logically, but don't design for different environments.
19:22
Design for features. You build for features, and what does it mean? When you build for features, it looks like this, that, okay, you get a century DSN, and when this is defined and not known,
19:41
you configure this. And the same thing for the debug. When debug is true, you do something that you don't do when debug is false, obviously, yeah. But you don't design for, I do debug only in the development. If you want to turn it on in integration,
20:02
it should be possible. And so you build for features, and you compose those features in environments. So you compose it for the environments. Then the development layer. This is actually about the tooling
20:24
to how you do proper software development, how do you do professional software development. Let me go back to the application. This here should actually just work like you did software development 15 years ago. It's just I'm doing some hacking,
20:40
and I do pip install Django, and then I do create, manage by a new project, and then I start hacking, install everything locally. So it should work like this. So this makes you independent. And then for development, this is a separate layer.
21:00
You have, what do you have here? Yeah, you have the TOX configuration that helps you doing the tooling with, yeah, with all your Python stuff. So without having to install the thing separately. This helps. You only need to install TOX. Then you have, of course, you have the test, because professional software development, you do that.
21:23
You have all kinds of tests, acceptance tests, unit tests. And for easy development, you may have something like a Docker Compose, which of course then goes into the deployment, the deployment configuration that, so the Dockerfile, we'll see that later.
21:40
Yeah, but make it easy. Use standard practices, so no makefile or something. If there is a Docker Compose file, every developer knows that, yeah, you write Docker Compose up, Docker Compose build, and it just works. You know, you do this like this. It's Docker Compose up.
22:00
I actually may do the build. Also, put this in demonized, because I want to do the migrations later. Yeah, so don't write lots of instructions, comprehensive instructions. It should be simple and user-friendly, you know.
22:20
So when something is logic, it must be logic, and not in the documentation, the Wiki, or not even in the readme. The setup wasn't super logic. I mean, Kubernetes is complex. And then you have the deployment kind of responsibility layer, which is actually just concerned about everything
22:41
that is about deploying to environments. And of course, your local machine, or when you develop in containers, it's also an environment. So that is where you, by the way, would turn on debug, for example. But you could also turn on Sentry, and that should be completely at your disposal,
23:01
and not, you know, kind of a decision made by design for environments. And so there is the Dockerfile in here, everything that belongs to the Dockerfile, the uWSGI-ini, and so for the web server, for the application server, and or a unicorn, whatever you want.
23:21
And this is important, that this is a separate file, so you can inspect it like you would inspect it as a uWSGI hero, microWSGI hero. You would look into that. Don't put it in a YAML file. Don't mingle it into YAML files, for example. And the same for the web server. Don't mingle that nginx configuration
23:42
into the YAML files. You can do that, technically, but it's like PHP developers mix HTML with PHP code. Don't do that. It's difficult in Django. It's almost impossible. So don't do that in YAML. Okay, and for the secrets, of course, you should put them in your repository.
24:01
That's the new thing. But of course, not in plain text, because if you don't put them in the repository, you can deploy it. You can have complicated things like the vault, but the simple thing is you seal the secrets, so you encrypt them with a public key,
24:21
and only the cluster has the private key to decrypt them, and you have a kind of Kubernetes operate there that decrypts it. All right, and then the automation. That's the simple part. Keep it simple, and let the CI service do what you would do manually.
24:41
Don't install things in the YAML, you know. Let's take a look at that. So you don't do kind of install things here. You have an image that has TOX installed, and that, you know, that does some things here.
25:02
You say, okay, the test image, the test, actually, that's just a kind of template. So the test thing has a TOX image, and I test for PyA3.7, and it's not installing anything.
25:20
It's all there. It also speeds up your builds, and it should also be nicely readable, so you know this is, Pylint is checking here. You should be able to tell a story with that. This here is deploying to integration only for changes on the master branch, so when you merge a MetroQuest into master, for example,
25:42
into the main branch. This deploys to production and only when you push a tag, so you can tell a story, and guess what? When do we deploy to the development environment? Only when we open a MetroQuest, so this is nice to read, and that's how it should be.
26:01
Tell a story and make it as simple as possible, okay? So, and there are some other, yeah, terms that, or considerations I would like you to follow, so it's the ASAP. When you hear ASAP, don't hear us.
26:21
You know, don't hear the usual thing. Hear as simple as possible. I'll show you why, and deploy early, deploy often, and that means deploy from commit one and directly to production, so by the way, what do we do?
26:41
Let's check what happens in the meantime. Yeah, this already deployed, so we can see here the builds. Yeah, that's building. This is just Docker, you know that. I don't need to show this. So, and, but by the way, here, the test, for example,
27:03
that looks like just it looks on your console on your local machine, yeah, and then for the deployment after building the image, the image was pushed to the Kubernetes cluster to OpenShift, actually, because it has a registry, and then for deployment,
27:21
yeah, this looks a little bit more complicated, but these are just OC commands, single commands, so you have one image that does everything, and the good thing is here, this is nicely integrated. Let's take a look where this ended up. There we go. Click on link, and there we go.
27:41
Well, it's stuck for some reason. Yeah, this is the usual demo God, yeah. Let's check back later. Usually, this is because Django needs to wait for the database, but this is actually
28:01
waiting a little bit long. All right, so let's take a look at the process, by the way. So we said merge requests, you remember, they end up on development. When you merge a merge request,
28:22
so you make a change on master, this ends up on integration, so I pushed directly on master for the first commit, so that's fine then. Afterwards, it should be protected, that would be good, so you can only do merge requests, and then, so for triggering a deployment,
28:45
you just push a tag. So you do something like git, git tag 1.1 over say, and you say git push tags, and then the tag is pushed,
29:04
and what happens is that we get a thing running the initial commit that will deploy to production. The image is already built,
29:20
so we don't need to build it again. So, by the way, what was that? Docker compose exec application, oh yeah. What is it?
29:42
Python manage py migrate, right? So that is for Django, yeah, that's cool, and then I can do everything that you know when you know how to work with Docker compose logs, I think logs minus F, right?
30:02
Yeah, so it does something. That was because we had no migrations, and that is actually, so when you stop this, Docker compose down, Docker compose up.
30:20
You can see this directly, yeah, and that's easy, I have the link here, I can click on it, so this is just saying not found, because this is actually, there is nothing here, but this is actually running. This is actually running a Django application,
30:41
because we have the admin, we don't have a front page here, so yeah. So we can see the request here, and this is actually a nice trick that you can do this like this, and yeah. We can see this, we can see this trick in the Docker compose file,
31:09
so we are not even running the web server, we are actually doing what you would do 15 years ago, or 10 years ago when Django was born, you would just run Python managed by the run server,
31:20
and then you can click on this, and it's actually, this is running inside the container, but I can still access it, because we have configured it correctly, like this. So but it should be nice and easy to use. Good, then where did we stop? Yeah, okay, and then of course you commit,
31:43
you push your first commit, okay, it's not worth anything, because you don't have a front page, yeah, but you iterate, you improve, you add monitoring, you add actual tests, because the first tests are dummy tests, and so on, and then, I mean, just the usual crying of us
32:06
that do agile, do test-driven development, do a pair program, make pair programming first, you know, do that first, because you get more things done when you have two heads doing things, and when, and try to tackle the test-driven thing,
32:24
try to write the tests first, a single line of code in the test that must fail, a single line of code in your code, in your application, that makes the test pass, back and forth, back and forth, only a single line, that's how you do it, and you have to do this, go attend a workshop
32:43
on some PyCon, and so this is super, when you experience how good this feels, you're never gonna write code without tests again, and free your software, so this is more for, you know, general consideration for projects. The less code you have to maintain internally,
33:03
the less burden you have in the end of, okay, open source, free software projects are a burden of a different kind, but you are, you force yourself to make it nice, you can't just leave, you know, your code base without tests because this will harm your reputation, for example,
33:24
and when you have no secrets, or when you have no closed source, or you have very little closed source, you have very little security holes, ideally, and hopefully when you make this popular, then you have people looking at the code
33:40
for security holes, yeah, and that is what Robert C. Martin says, the only way to go fast is to go well, and I know people don't believe this, so let's look at this, whether he says this for real.
34:04
Tell your friends in technology that the only way to go fast is to go well. Okay, if you don't believe me, believe him. That was basically it, so if you want to try out the cookie cutter,
34:21
you can scan the QR code, or click on one of those logos, and we are open now for questions, but I may suggest before we start the questions, because we're all Pythonists, right, and who is a Pythonista?
34:40
Hands up, so, and then you know the oath that we have to speak, so speak with me. Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicate, and people are leaving because they get scared.
35:00
Flat is better than nested. Sparse is better than dense, and readability counts. Special cases aren't special enough to break the rules, although practicality beats purity. Errors should never pass silently unless explicitly silenced, and in the face of ambiguity,
35:20
refuse the temptation to guess. There should be one and only one obvious way to do it, although that way may not be obvious at first sight. Take some time. Now is better than never, although never is often better than right now.
35:41
If the implementation is hard to explain, it's a bad idea. It is one. If the implementation is easy to explain, it may be a good idea. Continuous delivery is a honking great idea if you deploy it to production from Comet One.
36:01
Let's do it. I start today, Python. Thank you, Peter, and especially for your live demo. Very interesting. And I think we have time for some question.
36:24
You talked briefly about secrets. My question is, how do you inject the private key to the container? Yes, that's a fair question because I talk about secrets,
36:42
and I actually expect that people say, why to deploy it to production? You don't do this. Anyway, maybe someone else will ask it. So the typical solution you do with Kubernetes cluster is you run an operator. So you run practically a service
37:06
in your cloud instance that has the secret key in there. But there are other ways. I'm really not a test expert. I'm not a Kubernetes expert.
37:21
I'm not a Docker expert. I'm just telling you what you should do because Uncle Bob says it. But it works. I mean, we do it. Yeah, yeah, yeah. And people are struggling with the vaults. And when vaults are down, they are the single point of failure.
37:41
But man, it's everything. When the cluster is down, it's a single point of failure. Another question? I've seen that you deploy the merge request code to a development environment. So how do you handle if there are several
38:01
merge requests open in parallel that all have to be reviewed? Yes, so the typical answer is GitLab review apps. I've not done this here for simplicity because it really depends on how big your team is and also how much you want to spend.
38:22
Because the concepts are nice to explain. But in the end, there are business people that say, okay, you need more RAM, you need more CPU. This costs us 50 francs more a month. No, no, no, no, no, we don't do that. So the easy solution is to only have one instance.
38:41
So and then it's all about discipline. So if you have two, three developers, they say, okay, now I'm pushing my merge request. I'm opening merge request. And yeah, it's not the ideal way, but it saves money for the customers and we have such customers. And for the others that want the cool solution, we do review apps and you can find this
39:02
in the GitLab CI documentation. Thank you. Other question? I have a question. So you mentioned cookie cutter and I already heard in other talks. And do you recommend you use it every day for creating the template?
39:24
Well, I'm in DevOps, so I'm not creating the templates. It's for me, it's mainly, yeah, I'm trying to help bootstrap others. I mean, what we also do, what I plan to do is have the creation of the different combinations automated.
39:44
But I'm not using it on a daily basis. For me, it's more like, you know, how do I put the things that we see every day and ideas evolve and we find out new things. For example, we have some kind of Git pool now
40:01
in the build step and this is weird, but it makes your build faster when you cache the image layers. So I need a place to put that information somewhere. So I put it in the cookie cutter and there are other tools. I know there's some, something that I started with,
40:23
but cookie cutter is popular and yeah. It has some defects because you can't upgrade really the code you have created, yeah. Thank you. Other question? Hi, how do I prevent getting locked into my CD tool?
40:43
In this case, GitLab. Excuse me, I couldn't hear the first part. So you've chosen to use GitLab? Yes. But now you're essentially locked into GitLab because it's all very specific configurations. How do I avoid that?
41:00
Yeah, so the point is you have seen I presented those layers and the GitLab is practically only the, should I go back? GitLab is only this automation layer. So it's the last layer here. So my idea is to, so what we create,
41:21
what I create is in an automation, so a Bitbucket pipeline configuration or a CircleCI configuration or a Travis CI configuration that fits with the deployment, for example, that runs all the commands that work,
41:43
that are designed and that are compatible with the deployment layer. So that's the only thing I have to do. And for building, well, it's actually just the deployment layer, yeah. Because there you build the image for building and then you run the OC commands or kubectl commands for deploying.
42:03
So that's how you solve it. You generate this and you take what you wanted, Bitbucket pipelines, YAML file, put it in there and you push that to a Bitbucket repository. Does that answer your question?
42:21
Thanks so much. Other question, yeah. Hi, so I'm just trying to understand. So, okay, this is Python conference, but are you like proposing all those things with what you said?
42:41
So they should work in like language and technology agnostic way? Or is this somehow very tied to Python and Docker and so on? Why I'm asking this question is because when you talk about production for everybody, production is a different thing. So right now, as I understand, it's just a Docker container
43:00
which is deployed somewhere, right? This is the end product of this. Yeah, that's the cloud, yeah. The cloud is just somewhere else. Yeah, so I mean, other people have different types of production here. For example, they release, I don't know, RPM packages, Debian packages, which then have to be manually installed and so on. No, you don't have this.
43:20
If you do Docker, if you do containers, you don't have this because you can run a, you can install everything in your containers. Everything is in your Docker file here. So you do what you do. I mean, you're talking about traditional deployments,
43:41
correct? Yes. Yes and no. So my point is, Docker has also security concerns. So that's why not everyone is, you can use it for testing sometimes, but not for deployments, yeah? Deployments can have different procedure, I mean, to production, yeah? They can have completely different procedure from, for example, what you do in development.
44:01
No, but if you go through the talks, through the slides again and try to understand how, I mean, it's really when you work with containers, it's completely isolated. That's the whole point of containers, that you don't have to worry about what does my target environment look like.
44:22
You don't have to worry about, you don't even have to worry about processors and all that stuff because in the end, you don't even have to worry about when this happens with Kubernetes because you only say, hey Kubernetes, look, there is an image, you push it somewhere. No, actually for, to Kubernetes, you only say, here is the configuration. And then, Kubernetes has a concept
44:44
that is called eventual consistency. So it does not immediately deploy. It deploys when it thinks it's right. So when the time has come, so kind of, you know, so it kind of fires up your container and when that works, it shuts down the older one.
45:03
So you don't have to worry about this and the solution is containers, but this is not my talk that explains that. This is just why we use containers. Okay. Is this okay for you that I'll answer it in this way?
45:23
Can you give me the mic back, please? Yeah, we have to... So in some companies, the installation procedures are much more difficult than this due to security concerns and due to machines being in some remote locations and so on and so on.
45:41
Yeah, but it doesn't work as simple as this. But let's solve this now. For local development, it's okay. You can use the container. No, no, not at all. Local is just one environment, you know? That's the point. And everyone needs to understand this. This is critical. There is no local environment and there's no production. That's why I say production
46:01
because hopefully some people will jump up and say, no, we are not deploying to production. This is dangerous. It's not. You know, it's just one environment. You know, the point is you can give, if you have security concerns, you give the Docker containers to the people that deal with security and they will make it secure.
46:20
That's the solution. So it's not my talk. I'm taking this for granted because the industry now works like that. If you and your company don't work like that, again, you should catch up. You really should. Thank you, Peter. We are free and for this session. And thank you for your time
46:41
and we can proceed with the other talk. Thank you.