#38 - Joseph Njogu -Dev Ops

Ever wondered how to accelerate your software development and deployment cycles? This episode is packed with practical insights and actionable strategies for CTOs and senior engineers aiming to build a high-performing DevOps team. We start by tackling the core principles of successful DevOps implementation, from defining precise goals to selecting the right tools and skills. Emphasizing the mantra "you build it, you ship it, and you run it," we uncover the importance of team involvement in every stage of the software lifecycle and how to measure success using key performance indicators like deployment frequency and mean time to recovery.

Navigate the intricate world of DevOps tools with our comprehensive guide, covering everything from Docker and Kubernetes for containerization and orchestration to CI/CD tools like CircleCI and Jenkins. We delve into infrastructure as code with Ansible, Terraform, and Pulumi, and explore the role of configuration management in a multi-cloud environment. Whether it's cloud services like AWS and GCP or on-premise deployments requiring hardware and networking expertise, we provide a detailed roadmap for selecting the best tools tailored to your specific needs.

Integrating security into the DevOps process is crucial, and we explain how automated testing and idempotent scripts can fortify your applications. Discover strategies for transitioning clients from legacy systems to modern solutions, balancing technological advancement with customer satisfaction. We also touch on MLOps, emphasizing the synergy between DevOps and machine learning, and dive into tools like Docker and Airflow for enhanced automation. Don’t miss our discussion on the essentials of multi-stage Docker files and their role in efficient container deployment, complete with practical examples. Join us for an episode that promises to elevate your DevOps and MLOps practices to new heights.

Chapters

• 0:09 Building Successful DevOps Teams
• 11:53 Choosing the Best DevOps Tools
• 32:07 Selecting Tools for Different DevOps Environments
• 44:03 Approaches to DevOps Automation
• 53:05 Exploring DevOps and MLOps Integration
• 1:12:34 Testing and Roles in DevOps
• 1:30:14 Integrating Security in the DevOps Process
• 1:44:28 Configuring Multi-Stage Docker Files

Transcript

Speaker 1: 0:09

Okay, I think we can now get started. Just an overview before we begin, I'll just do the reminder again. What we'll do is we'll have a presentation and then, after that, a slight break and an interactive session. After All, right, yes, so the topic today is DevOps for CTOs. This is CTO Roundtable, so I'm assuming, or I believe, most of you here are CTOs or senior developers and engineers in your companies, so this will be an engaging session for you.

Speaker 1: 0:41

What we're going to do is, during the presentation, if there are points you want to note or areas you want to hear more about, or areas you even want to share with other people who are here today, just note them so that during the engaging session you can get to share. We'll have that space to interact. All right, awesome. So we will get started. And we also have our SRE Site Reliability Engineer from Africa is talking here with us, called Edward. Hi, edward, yes, so he will get to share insights later. And so, for now, I will welcome our presenter for this evening, who is Joseph Njogu from ArcRide. He's a DevOps engineer at ArcRide. So, joseph, welcome and take over.

Speaker 2: 1:32

Round of applause. Hi, yeah, that's new, that's new. Okay, so I'm Joseph and, as I said, today we'll be talking about DevOps for CTOs. But before I do that, because I'm joined by my good guy here, edu, let's introduce him. He'll give us an introduction.

Speaker 3: 2:00

Hello guys Again. My name is Edward. I'm a liability engineer engineer in Africa, stalking. I started doing this role in 2018. So I've been doing this for some time.

Speaker 2: 2:17

Awesome, so you are the CTO. I heard you say you are the CTO. Do you have someone who joined in 2018 like him? Do you have someone who joined in 2018 like him? Awesome, ok, yeah, so today, our main focus will be two bits how to build a successful DevOps team and maybe to highlight some of the best not the right, but the best tools which are used in the industry. Yeah, so that will be our main focus. And, because we said the session is supposed to be interactive, we have other DevOps engineers who work in different companies. We all maybe know how we did to build our DevOps teams, right? Yeah, so just start. You all maybe know how we did to build our DevOps teams, right? Yeah, so just start.

Speaker 2: 3:08

For the first bit, they are building a successful DevOps team. It's almost something straightforward or something logical. How to do that? Number one, maybe ask yourself why do you need a DevOps team? Or maybe why do you need DevOps in your company? Right, yeah, so maybe, for because we are developers here and DevOps engineers, why do we need a DevOps team? Or why do we need a DevOps engineer in our company? Yeah, so maybe. Number one, we want to, you know, hasten the process of the software development, or maybe the deployment cycles or frequencies, right, yeah. So number one before we now maybe we know why we need a DevOps team to hasten that process. Or maybe we want someone who will manage our infra, will manage our, who will be doing the deployments for our company, right? So maybe number one to do is to define your goals. What do you want to achieve by the DevOps team? Yeah, what do you want to achieve? It's a question for you to answer, because it's you who want to have the DevOps team in your organization. Number two ask yourself how many tools do we have out here for DevOps engineering? Because you, as the city of the company, will maybe take a lot of time to define the tools that you want to use, not any other person coming into your organization and saying this is the tool that you want to use. You're the right person to say this is the tool that you'll use. So how many tools do we have? What tool do we use for this task? Right, yeah? So the next thing is to ensure that we assemble the right team.

Speaker 2: 4:59

Now, this is the bit where we have the real talk. How do you assemble the right team for you? Definitely, number one one thing you will realize is that maybe in Kenya right now, devops engineers are not paid the right amount of money, so most of DevOps engineers are working remote. So you'll need to think where do I need to get these people? Where are these people located? So do I need to put my team on site or do I need these DevOps engineers to work remotely? That's one.

Speaker 2: 5:39

Two do they have the right skills. When I say the right skills, okay, I believe in the mantra by Atlassian that says you build it, you ship it and you run it. So be the developer who builds, be the developer who ships that product and be the developer who runs that product. And in that you have the right DevOps engineer. Yeah, so ensure that the DevOps engineer that you are getting, he or she is a developer. Two he or she has the right skills, or rather possesses the skill set with the right tools for you, or maybe the best tools as you define them. Then, from there, now assemble your team, have them, set your own objectives. This is what we want to achieve, we now, as the team of these DevOps engineers.

Speaker 2: 6:39

Right, then ask yourself how will I measure the success of my DevOps team? How do I measure that? Because I think the KPIs that are driven by DevOps are the ones which are the most important, like number one the frequency of your deployments. How frequently do you deploy your projects or your applications? Two, what is the mean time to recover when you face an error? So when I said you get a team or a DevOps engineer who can build, ship and run, now try and think in this line, you have a DevOps engineer who would not participate in building a certain product. Then we face an error in production. Do you think that DevOps engineer will solve that problem? The answer, maybe, is yes or no. Yes, if he or she is a developer, right, but he'll take a lot of time to figure out where the issue is if he or she is not the one who built that product, right. But now think in this line this DevOps engineer not the one who built that product right, but now think of this line this DevOps engineer is the one who built this product from the very beginning and the same person who shipped this product. How long do you think they'll take to solve that issue? Very little time, right? Yes, so now you see the sense behind that. Yes, so in this, now, before you assemble this.

Speaker 2: 8:08

Now, as we said, define your goals. Know what you want to achieve. Right, remember when you are starting. Maybe, if you are a startup, maybe initially you have a very small number of projects that you want to be working on. But think in the future. Right, what will we maybe be building? Because you might, right now, bring someone a DevOps engineer with the right skill set at that time, but how about tomorrow? So now, that brings another aspect that you will consider when building this DevOps team Number one build a path that these people will be following to upgrade their skills. For instance, maybe have something like create a token where you reward your DevOps team or engineers to get courses, upgrade their skills, because I think growth is the most important thing. Right, we all want to grow as DevOps engineers, not just fit in our current companies, but to fit globally right, and to also build scalable applications which are world-class. Now, that's that bit, and definitely it follows other things which you, as the CTO of the company, knows. This is what we want Maybe someone who is a leader, someone who can lead others, who can be a mentor to, you know, junior DevOps engineers and other people.

Speaker 2: 9:38

Right, and also not just being a leader, but also someone who is a speaker. Now, try and imagine I was not a speaker and I'm a DevOps engineer. How will I pass the knowledge to others? You see, yeah, not saying that everyone is a speaker, but at least someone who can Also maybe assemble. Maybe we can assemble this one company, but these are the DevOps engineers of this company, and here he is giving them the knowledge or telling them maybe what to do. Right, and remember, I said this is an interactive session. You know it, I know it, or we know it, or I don't know. You know right, yeah, cool, yeah. So in that bit, maybe, if we can get someone else who is a DevOps engineer, what can we add in that bit of building a successful DevOps team, apart from what I've said? Anything, anything. The CTO what did you do when you were building that DevOps team? That I've not said Okay?

Speaker 5: 11:03

he's saying she's saying repeat that, okay, I think we understood the why, which is important. Thereafter we just we didn't know what we were getting ourselves into. So we just knew that we needed to get there and this was how to get there. The DevOps we got into just trial and error, and right now we can say that we're pretty comfortable and confident of where we are.

Speaker 2: 11:34

Awesome. And also I hope you know that by 2015, almost 55% of the companies in the world had adapted DevOps. Now you know, yeah, so let's get into that other part here. This presentation is very short because I said, you know, the most important bit is where we are all interacting with the right questions right Now. This bit we said define your goals, assemble the right team is it maybe already right? Create a culture of continuous improvement. When you have that, you'll see the need as to why you want a DevOps engineer. Or maybe just educate one of your developers and become a DevOps engineer. Right? It's another way of creating a DevOps team Embrace automation. Which company have not embraced automation? That company is lagging behind right Now. And this part where I said the KPIs of DevOps measure your progress and it's just only by the use of those KPIs that you'll know you are progressing or not. You'll now say do we need the DevOps team or we don't need it? Now, this bit here implementation of DevOps. What did we do to implement it? Now that we have the team, we have the right people in our teams.

Speaker 2: 13:12

Now, mostly what we'll cover here are the most commonly used tools not the best, not the right tools, but the best tools In development environment or in software development field. What do we mean by the best used tools or the best tool to use? How do you know this is the best tool to use? Developers in the house, awesome, yeah, definitely, community support. Larger developer. You know environment? Because just imagine, you face an error and you don't know how to fix it and the tool you are using is not used by many people. So the best tool is used by many people, right? So we have here these ones and definitely we have the alternatives, because I know some of the other companies are using other tools, but I don't know if there is any other company which is not using Docker or we are not using Docker. We are right.

Speaker 2: 14:22

So Docker is one of the most commonly used tool for dockerization, containerization, or bundling our projects or our applications into standardized units, that is, containers, which is one of the best use cases for bundling our projects, our project. Then we have Docker Compose here. How many people use Docker Compose here? Exactly, docker Compose, if we are not using Docker Compose for these kubernetes, right? Yeah, so the alternative for Docker Compose is Kubernetes, which I think for you to use Kubernetes, you must be having very strong reasons, right, not just a reason, but very strong reasons. Maybe the load that you are carrying, the traffic, the number of users. Also, definitely if you have a lot of money, right yeah. Then we have DocHub there. But the reason I just used DocHub just for illustrations I know most of us use, maybe ECR this is the container registry or image registry. So some of us use Doc Hub, which is open source, others use ECR, others use GCR, right, yeah, just for storing our Docker images that we create up there. Then we all know that.

Speaker 2: 15:59

Where do we start in DevOps? When you hear about DevOps, where do you think you are supposed to start exactly? So DevOps starts at CI, cd, right, yeah, so we have a circle CI there. Other people use github actions, but these are commonly used but not the best ones, right, the best ones are something like Jenkins. People use something like GitLab CI. Others use Travis CI, teamcity, bamboo, etc.

Speaker 2: 16:35

But definitely, as we said, know the tools that you want to use. Do some research before we say this is what we'll use. We let cover your objectives. Objectives how usable is it? How is it user base? Right, like, for instance, I could say right now, so, because he is used by 48,000 organizations globally for GitHub actions. I know it's almost every developer, right? Almost Not everyone. Then we have another tool here, a very simple tool. Now, when we move from CI CD, we now start thinking about infrastructure as code, right, or rather, it's thinking about the infrastructure. Where do we want to deploy our work? Where do we want to like? Where is our prod environment? Most of us use infra as a service. Yes, right, and maybe a small number using pass.

Speaker 2: 17:37

I don't know if everyone uses that, but yes is the most used, not unless you know you want to focus a lot on the business logic and leave the management or the configuration of your infra to the organizations, right, yeah, so when you want to achieve that infrastructure as code, we have a tool here called Ansible. It's a very nice tool to use, called Ansible. It's a very nice tool to use. Ansible, used by around 20,000 organizations globally. Alternative for that, we have Terraform right, we have Pulumi. Those are the best ones. Why am I saying the best ones? You know we have something like CloudFormation, but it's one of the best. Why? Because when you're thinking as a DevOps engineer, you're supposed to think about multi-cloud, not just focusing on one cloud provider. Right, when you talk about CloudFormation, you just talk about AWS, but when you talk about Ansible, terraform, pulumi, you talk about multi-cloud. Right Now, remember I've said Ansible has IAC, that in infrastructure S code, right. But remember, we also use Ansible in another format or for another use case. That is, configuration management, right. So for that configuration management, we can either use Ansible, chef or Puppet, right, just depending on what you want to use. The reason I say it here is because, like, okay, when we build Docker images, we tend to run them on Linux-based environment, right? Linux, by default, is based in Python. Ansible is based in Python, so the best tool to Python, ansible is based in Python, so the best tool to use Ansible. Then, on cloud, also, think about most people I know are using AWS, others GCP, I don't know Azure. How many are using Azure? Yeah, so most of us are either in GCP or AWS, which, again, before you now go into this, you have to ask yourself do I need to hire two groups of people? Do I need to hire a DevOps engineer and a cloud engineer, or do I need to hire a DevOps engineer who has cloud engineering skillsets? Definitely, by defining your goals, you'll know what to use. Again, in terms of access to our infrastructure that you have in cloud, think about something like SSH. I know this one is not new to you guys, right? Ssh, ssh I know this one is not new to you guys, right? Ssh Straightforward right? You don't have to say this, it's straightforward. And yeah, because this was not meant for developers, it was meant for CTOs. In fact, he processed how, by a, yeah, could build an image high queen, of a. If I think about right now, the right tools. Definitely have not listed all the tools here to use, like I want us to go into another small section here to isolate every other part of DevOps and know what you need when getting the right people.

Speaker 2: 21:15

Now, when you talk about DevOps, you talk about Linux. So someone is supposed to be having Linux skill set, right. Then the next thing when you talk about cloud, you talk a lot about networking. So VPC In AWS, they talk about cloud, route 53, right, there's something like Route 53. So talk about that thing. Gateways, internet protocols, yeah, so networking, linux. Then definitely you are configuring or managing cloud environments. So talk about cloud.

Speaker 2: 21:53

What cloud environment or what cloud provider do you want your DevOps engineer to have? Do you want him or her to have all of them or just one? Then talk about configuration management tools. Which one do you want to use? Do you want to use Ansible Chef or Puppet For infrastructure as code? Do you want to use Terraform or do you want to use Pulumi? Pulumi is, they say, it's language antagonistic, something of that sort. You can do Pulumi with any language Python, c, sharp, Java, golang. That is Pulumi. So which tool in that category do you want your DevOps engineer to be having?

Speaker 2: 22:38

Then, from configuration management, you talk about now the CICD, which platform or which skill set or which tool you want to be having? Circleci, let's remove Git in that category CircleCI, travisci, jenkins, gitlabci For those who are using GitLab definitely GitLabCI. Circleci is configurable with, or integratable with, github. How about Bamboo? How about TeamCity? See, then you start. Now, those were the tools for ensuring build of your product.

Speaker 2: 23:15

Now, how about when you want to run your product, tunai Lewa, when you run your product, you build, you ship and you run, run. Run definitely means now where these guys reside, the infra, the time when your application is in operation, that is, we are not talking about monitoring that bit. So we know, like it to like Grafana, prometheus, if maybe you are dealing with time series data, you need to talk about the TIC stack, that is, telegraph, infraxdb, chronograph and capacitor. You need to talk about those things. Then maybe you want to be. You have a lot of search in your application. Now you talk about the ELK, elasticsearch, kibana and Logstash. Those are the things you need to be talking about now. Something else a very nice tool for monitoring Prometheus. Right, talk about Prometheus. Prometheus and Grafana go hand in hand, right? Yeah, so those are the things you need to talk about or to think in that line, but definitely comes handy when you are defining your goals.

Speaker 2: 24:35

To what extent do you want your DevOps engineer to go, or to what scope is it encapsulated? Okay, yeah, so in that category. Then again, you talk about a programming language. We said ensure that your dev, your devops engineer, is a developer. If you have developers and you just want him or her to be a dev engineer, you might maybe look into the scripting aspect of it, right? Ruby, go and Python for scripting purposes. Yeah, so that's one programming language, to at least have one programming language. What else have I left? Okay, and definitely I think that's it not, unless we have questions in that bit. Definitely I didn't exhaust everything. Maybe you can tell me something that I didn't say, or maybe you expected to hear about something that I didn't say. We will say what we will say.

Speaker 9: 25:59

In the flow that you have in, I think, the first or second slide. You have measured there. I'm not sure whether I've seen anything in terms of tools that are on measurement measurement of the whole DevOps process.

Speaker 2: 26:20

In that the KPIs. Those are the KPIs, not necessarily having the tools that measure that you had your objectives right Now. One of the KPIs is the mean time to recovery when you have an error, like how long did it take to recover from a fail? So that is one of the measurements, not a tool for measuring, okay. Then another one is the frequency of your deployments how often do you deploy, how often do you deliver your latest builds? I answered not a tool for measuring, but those aspects, the the KPIs, key performance indicators.

Speaker 7: 27:07

Okay, yeah, another question so I was just wondering from the measure part have you heard of people using time series models on that like ML models?

Speaker 2: 27:38

People using ML models. Time series DB yeah, okay. Or time series stuff. Time series DB yeah Okay. All time series data yeah, we do, because we are IoT-based company, so we deal with a lot of data and we have a time series data because you know, when you're talking about fleet management, when you're talking about the sensors in the iot cards, all based with time, all based on time yeah, so in terms of that, you have tsdb, that is, the time series database specifically for that tsdb, leave alone the interest, the influx db for that yeah. So what's the question?

Speaker 9: 28:22

If you're using it to do the or stop waiting for all the progress.

Speaker 2: 28:32

I see that bit. You are saying like anomaly detection, okay, so if, okay, that is not DevOps stuff, yeah, we are doing that for anomaly detection. I'll give an instance. Okay, I said I work at Accred. We work on EV, that is, electric vehicles, and when you talk about EV, you talk about the ECUs, that is, electronic controller units, right, and the motor controller unit. Now, in the ECU, you expect a lot of fails to happen, or maybe minimal fails to happen, based on conditions, maybe, like, for instance, it's raining, you expect if that ECU gets in touch with water, some issues might happen, or not just instant, but you expect something to happen because of the performance. It's not normal as it is always right. Yeah, so to do that? You definitely know. You say the ML models for predictions, definite predictions, but that is data science, not DevOps, really.

Speaker 3: 29:47

Hello. Yeah, I would say it can be extended to cover DevOps, because I know his name is Ben. He's our data engineer and he's been helping us in working in that area. Basically, we want to focus more on the males, so basically we can predictively anticipate errors, like all such issues here.

Speaker 2: 30:25

OK, has he Exactly? Yeah, because I think the only thing mostly he'll do in that bit, you, as a data scientist, you will have that model. You will build that model for predicting right based on some history or maybe based on what you anticipate right, but his work mostly will be deploying that model or monitoring if that model is working as he expected or defined right. In that line though Not that I'm answering the question fully, but in that line, right. Yeah. So another question from back there. Kevo, you had a lot of questions. Okay, another question.

Speaker 10: 31:31

It's a long story, okay, okay. So I'm good, let me, but I was addressing it to you, so let me, but I was addressing it to you. So come sit here and I come sit here. What the difference like? How would you, what would you recommend? We have two applications. This application, you're the one developing it, then you host it to your customers, but this other one, you develop you ship to be hosted to the customer side. So, in terms of, I believe you are experienced with the devops industry. So, in terms of tool selection, team selection, can you just take a brief to describe how you will differentiate the tool selection and team selection for the two applications?

Speaker 2: 32:51

Now you are saying, in a scenario you have two applications. One application, say, you are saying it's for the client side, you want it to be hosted by. Okay, In the client side. What do you mean by that? You develop your application.

Speaker 10: 33:19

Then you tell the client these are the specs I want for you to have in your servers. Then you tell the client these are the specs I want for you to have in your servers. Then you host it there. Yeah, that's the difference.

Speaker 2: 33:32

Understood, edu. What's your question Now, according to what I've understood? Before I answer, this is a story that I've heard before. Right Now, you said two applications One you can host on your end, then the other one you wanted to be hosted on the client side. When I mean by that, you mean they have their own servers and by that quote-unquote on-premise server.

Speaker 5: 33:57

Right, yeah, but okay, before I answer, I think we are moving to cloud what is happening on, okay, there's some organization that don't do on cloud because of security and they prefer hosting there, and they have the capacity. A government, and you're talking about government all right that's a very nice question.

Speaker 2: 34:26

To be honest, now you want the tool selection for the two solutions, right? In terms of team or in terms of tools? Both, oh, thank you. Now let me come back here. Let's start with the first one, right? This one is an in-house product that you are building for maybe your own company and you will ship it on cloud, say on cloud, or maybe, yes, let's say on cloud. You understand that there are companies. If you don't, you understand that there are companies who build, you don't you understand that there are companies who build products which, quote, unquote they dog food. Understand that Dog food, like you build, and you are still the person who will use that product, right? So, with that, definitely, you want highly qualified people because, if, okay, imagine you're cooking food, so how do you do it With passion? Right? So you also want to hire someone who can do that, definitely, who understands cloud, not just understands, has its.

Speaker 2: 35:37

You know noise, ins and outs of cloud. Because we all know, okay, we have this meme, quote and quote again. We have this meme in a trend Twitter that why are you poor? Did you gamble? No, exactly, I left an EC2 instance running. So try and imagine you bring someone who does not know the ins and outs of cloud Then somewhere else, you know, maybe he's doing trial and error things. Then he starts or he creates an EC2 instance, then he just leaves it there. You can imagine the bill by the end of the month, right? Yeah, so one you want to have someone who understands cloud, because it's cloud we are talking about cloud. Leave alone even these tools that we have here, because I think the tools, we can always learn them, these tools. But here, before you interact with this bit, here, you must be knowledgeable with it. It's not just you know, it's not even a matter of leaving your EC2 instance running. It's a matter of knowing which is the best service to use. You know, not all service or not all applications you know requires to be deployed on, maybe, ec2 instance. Some requires to be deployed as Lambda functions. Maybe you need a serverless service, right? So you also want someone who understands that. Why do I need to deploy it on an EC2 instance? Why do I want to use a server? Why not a serverless? See Again. So those are the things. Understand cloud. That's for your team. Also, for the tools, definitely, we have them here.

Speaker 2: 37:23

If someone is not using Docker, it's just deploying an application in a bare server or a bare metal server. You have to think or to rethink, why go in that approach. And you know, when you use Docker you save a lot of resources, cpu, and it also gives you the leverage to deploy a lot of applications in one server, right, and maybe in one EC2 instance. If you're using an EC2 instance but I know the team here maybe the AT team can tell us they don't do EC2 instance when it comes to deploying Dockerized applications. So you have to think about most used AWS here, right? So we have the Fargate service for containers, right, think about that. So get someone who understands Fargate. So talk about someone who will understand how to integrate all these tools with the right service that you want to use Now on-prem. Definitely it's someone who understands the hardware, right, the hardware. You understand the hardware. But remember how do we access the server In a remote, even if it's an on-prem server, we access it using SSH, right, because we have the IP address, so it using SSH, right, because we have the IP address, so it's SSH. So definitely the tools he'll be using tools that use SSH. We have Ansible, so on and so forth. And definitely, if you say government, you'll know it's a series.

Speaker 2: 39:02

Yeah, so not just that. We said server networking, how to configure those servers. Okay, we have server and machines. How to configure machines? The server is the software, right? The machine is the thing carrying the server, right, I hope I'm not wrong. The machine carries the server, the server is the software. Am I correct? How about the machine? No, no, no, no, no, the software. Yeah, we say we want to spin a Linux server. Are we spinning a software or are we spinning hardware? Okay, I'm not really wrong, but the machine is the thing holding the server, the server. You talk about the software. Just do research. But that's the thing. The server is the software, the machine. Now, you have the specs of the machine, not the specs of the server.

Speaker 2: 40:46

So I think we can agree to this of the machine, not the specs of the server as a whole, setup, including the operating system in the actual machine. Ok, I won't say no. Yeah, so we are saying someone who understands configuration of that server. Definitely, either, on-prem mostly they use Windows Server 2012, linux servers yeah, definitely someone who will understand Linux for those. Maybe for the state, for the first time you are using Linux. Okay, maybe you've used Linux for the last five years.

Speaker 2: 41:19

How many times have that machine crashed? Your laptop? How many times have it crashed? Several, right, what am I even doing? Am I a Linux system admin? Yeah, so another thing you realize that initially, before we had the DevOps engineers, the SREs, the platform engineers we were talking about the system admins, right? So for on-prem, you want someones the platform engineers we were talking about the system admins right? So for on-prem, you want someone who is a system admin and I think when branching into DevOps, we have DevOps for system admins. So you might consider such a person if you have on-prem servers, right, are you unsigned a money semi-victim gaining?

Speaker 10: 42:07

because I'm saying, to a great extent you've answered, but especially on you know whether you are clear on team selection like, for example, they the in-house one, the one you are deploying as a service to the customer. You're the one hosting it. I don't know now which that that one, when you compare to the one that you are deploying on-prem to the client.

Speaker 2: 42:50

Yeah, to differentiate, we said when I was starting, DevOps engineers can work remotely or on-site, right? Definitely, if you have on-prem servers, would you still consider using remote DevOps engineers? Not necessarily because, okay, we said for them, they must, if not just a must, they should be system admins. Most system admins works on-site because it's on-prem, not cloud, right, Just because you want to fix it, because you know the power, you know what the CPU does, right? Yeah, on-site Maybe it's the only difference. But you see, the tools does not change, Tooling does not change because the mode of access SSH only the mode of working remote or on-site.

Speaker 10: 44:02

Okay, thanks for that. Now you are the owner of a product. Maybe there are clients who are using your product when it was still legacy. Maybe yourself now you are aggravating towards the modernity, but maybe your client is happy with a legacy version. How, in terms of DevOps, it starts with a culture. Right Now, in terms of instilling this culture, you don't want to lose this customer yet. You want them to go the modern way.

Speaker 2: 44:49

Yeah, again, a nice question. If I may give an example, you know of Atlassian products, right? Atlassian? You can either opt to use cloud products or on-prem products. So what does that mean? Maybe we are giving it your example. Some customers did not want to move to cloud, they wanted the legacy one which is on-prem, right? So we still have that approach where you can use the on-prem and there's those who can use cloud, just that, okay, maybe another example You're a data scientist.

Speaker 2: 45:29

We have this tool called Superset, right, superset is a tool for analyzing data or for doing analytics. You can either have it on cloud or you can do your own deployments on-prem, your own case how you want to use it. So it's for you now, as a developer or the owner of the product, to you want to maintain or to retain all your customers? Go with that approach. Or, if we have a lot of ifs, do I want to have the two approaches, cloud or on-prem reasons? Or maybe factors number one cost? What is the cost of maintaining on-prem reasons? Or maybe factors number one cost? What is the cost of maintaining on-prem products? Right, you know, you might be having maybe two or three customers who do not want to migrate, but when you compare the money they are bringing, all the revenue they are generating to your accounts, it's really small compared to the ones who will go to cloud Sacrifice Right. I don't know if I answered your question In automation what are the key areas?

Speaker 10: 46:52

in the DevOps environment.

Speaker 3: 46:57

Do we?

Speaker 2: 47:00

apply automation. Automation, edu, are you ready? We're answering him now. Automation. Before I answer that, there are three, isn't it the three virtues of a programmer? Anyone in computing, I bet I tend to think they are programmers, right? Virtue number one we say it's interactive. Virtue number one it's there, the three virtues of a programmer, programmers in the house.

Speaker 2: 47:30

Virtue number one laziness. Right, you said you're not a programmer, right, yeah. Now number one is laziness. Right, let's tackle laziness.

Speaker 2: 47:43

Laziness is like you're just tired of doing everything again and again, like when you wash your lap, the first thing you do is update, upgrade, install something, activate virtual environments, running servers, ensuring that all the services are now running, you see? So how do you do that? How do you ensure that you are lazy as a programmer? You automate that. So anything which is repetitive or recurrent, you automate One thing to consider the next thing or the next virtue.

Speaker 2: 48:16

Virtue number two is impatient, right, impatient. So you hate waiting. Do you understand what I mean by that? Like, imagine you have a task which is taking almost three minutes. Think when you switch on your laptop, then you take two minutes, two minutes before work. How does it feel? And then maybe you have one minute to join a meeting, you take two minutes. You see that. Now think of a test that you run. Then it takes a lot of time. You grow impatient, right? So what do you do to be impatient? What do you automate? Now, definitely, if you are impatient with waiting CTO, you want to tell us Now.

Speaker 2: 49:17

You said Optimizing, but now, before you optimize, as a software engineer, you measure, you measure. Yes, right, yeah, so before you optimize, you measure. Then the last virtue, the last virtue is hubris. Then you build a software you are very proud of. The third one is hubris. Do you know what hubris is? The one with the rings? You build a software you are very proud of because it's solving their problems, hubris. The reason I say the three virtues is because number one it answers your question why or what you will consider when automating. That's the first thing you look at. Number one when provisioning your infra on cloud, you look at. Number one you look at when provisioning your infra on cloud, when, maybe, using Playbook. Playbook is a set of tasks that you do Like you install Linux, sudo, apt, update, upgrade, install this, install that. Now what if you can write a script that will do all that in one-off command? Right, yeah, I hope I've answered. Yeah, any other question? Okay, polly.

Speaker 7: 50:49

Could you consider a makefile part of the DevOps thing?

Speaker 2: 50:58

Yeah, he is asking would we consider makefile? Right, when you talk about makefile, you say like make PDF, make this, make some Okay, I know that thing where you have funny, something right, or you're talking about the latex, live latex, it applies the same thing. Make, right, yeah, so make file. You are automating something like, for example, you want to have buildsh, that is for building your Docker image and pushing it to Docker Hub right, so you have make, yeah, one. You have simplified that process, all the repetitive things of doing it. Now, an alternative for okay, I want to show you how make is a part of DevOps. An alternative in Python is using fabric, where you have fab file, because fab file and make right, they go hard in hand. You have fabric and you have make. Even said the answer was a yes or no, in fact, right In terms of, okay, the way I consider it as a DevOps tool, before I come to that part where you now have to install it.

Speaker 2: 52:20

Now, there was a time I asked I had a presentation at Atlassian, atlassian and 80, right, yeah. So I had a question. You have a new joiner in your company. You are the DevOps engineer. How long should that new joiner take to set up a project that you have on your repository. How long A week.

Speaker 2: 52:48

No, I think the maximum amount of time they're supposed to take is 20 minutes to set up a new project or that project which is already existing on a repository is why you, as a developer or a DevOps engineer, you have this. You understand the aspect behind the dev containers, the remote dev containers in VS Code. Know that? The dev container? Yeah, exactly. So if you have a dev container, it means you and make file right. Yeah, because now you are creating another virtualized environment inside of VS Code that will be doing all the works in that project and make file is the thing, or rather, the make is the thing just to open up the conversation, I think you could, yeah, so that we can move the microphone so that those who are following along can hear when the questions are being asked.

Speaker 1: 54:00

So just yeah, proceed.

Speaker 11: 54:02

Thank you.

Speaker 1: 54:31

But just before, apologies, I will just disappoint you for five minutes or less. Let us then. The conversation is good and it's very engaging, so let's keep up with that spirit. Let's top up a bit of our energy, just so that we can begin with this session and continue for a while after, right, yeah? So let's take five minutes, stretch a bit, internalize, take down the notes and the questions you want to hear more of, and you can have snacks. Hallelujah, yeah, that's the announcement you've been waiting for the whole time. I got you so we can have snacks. Then we come back and proceed. Just five minutes, a quick five minutes. Don't change the mic there's a silence

Speaker 3: 55:35

on.

Speaker 1: 55:36

Twitter screen and then you start on Twitter.

Speaker 2: 55:48

I'm confused, hey, what happened.

Speaker 1: 55:56

All right, so feel free, danny. Thank you.

Speaker 3: 56:40

One two, one two, One two, one two. Testing one two. Testing one two is.

Speaker 1: 58:10

Thank you, okay. Okay, I think that break was needed. It seems you all were suffering. You didn't want to say a kidogo. It's hard to speak with no energy, okay, but now you're ready. You're ready. You have more questions and you want to engage further? Perfect, so that is it. We will proceed with the session. So, if you have questions around, just a recap what we have seen or covered so far, what has been presented, has been on DevOps, how to structure your team and best tools and what to consider, such as setting goals, the measurables that you should look at, the right tools, what to research on and the like. So that's where the discussion is centered around. For that, we will have our DevOps engineer, sre, site reliability engineer. I hear the word engineer is pretty important in this conversation, so I will keep it that way. They'll be here to engage further. So before we left, we had a question right over here. That's where we'll pick up from.

Speaker 11: 59:12

Hi guys. So my question was a bit straightforward. I wanted to know if there's a significant difference between DevOps and MLOps, and MLOps yeah, and ML Ops yeah.

Speaker 3: 59:33

Okay, maybe I can engage Ben on that, because, again, he's our main ML engineer our data engineer.

Speaker 7: 59:45

So when All right, thanks. So from the two cents I know about DevOps and MLOps so it kind of like merges. So like you, I think the part of MLOps is more of that thing called Kaizen, like for continuous improvement.

Speaker 7: 1:00:08

So for that, that's why I was supposed to kind of put things like automation in your workflow. So now stuff like Docker comes in, stuff like Airflow comes in, and I think where there match like DevOps and like ML, ops is just the part for the automation. So stuff to do with Docker and orchestration to do with stuff like Airflow and those normal stuff like cron jobs yeah, I hope that kinda clears the mist around that. I hope that kind of clears the mist around that.

Speaker 2: 1:00:54

Yeah, sure, and maybe to add the tooling yeah, the tooling for ML or maybe data in general, the tools are kind of different from other tools, like you see for orchestration. Like you see for orchestration when you say orchestration in front of a DevOps engineer, he or she will think of Kubernetes or Docker Compose, right? When you talk of orchestration in front of a data engineer, he or she will start thinking about orchestrating those pipelines, the ETR, the ELT, so you talk about Apache, airflow. To talk about superset, you talk about perfect, right? Yeah, so that kind of stuff.

Speaker 5: 1:01:59

Okay, so even the certain things is from the management side. So you've been technical and talking about the tools, but for there's a statement you started with knowing the why. So most people miss or do not have a clear goal of why they are doing DevOps. So there's quite a lot of engagement with DevOps engineers. There's a lot of talk about DevOps. Actually, the tools are quite known. However, the benefit driven from this particular collection of tools and people is not quite clear and the reason why I feel like the why is quite an important part and, as you mentioned it, why it will also answer to the aspect of what he has asked about MLOps and, I think, from a management perspective, how we see because our main question is usually the why the technical stuff that we can get, but we want to usually the why the technical stuff that we can get, but we want to know the why. So the KPIs do not matter what is in here. At least, once we know the why, we can measure the KPIs based on the team that we have, and the team will now come with the tools how, as you said, getting someone who is qualified to get the right tools for the problems that we have or the solutions that we have. So the why I feel like in DevOps there's a talk, there's a lot of talk about the tools knowing, and I've been in interviews and people really know the tools, people really know what they are for. However, when you get now to a situation okay and this is also the dilemma with engineers you come out of campus knowing computer science, but then you get to the world and you don't know where to apply it and what's the end product. So I think the best way to onboard DevOps and also goes back to what John was asking is the why.

Speaker 5: 1:04:17

As you see, in most offices there are some who have they're building their own products to serve their own market niche okay and those who are just builders of new solutions. You can be someone who is a freelancer. You're building different applications for different clients. How does that person entrench DevOps With an aspect of ML in it? Also, it will define someone who actually just is a company working on one application, as we were mentioning earlier, and then this application ends development On the client side. It's a whole new ballgame. You cannot access their servers. All you do is you're told build us the image, ship it to us Up to that point. Okay, sometimes it will be a bear. You'll just push the file, the deployment file, and send it to them. They won't even build a certain image. All you need to do is build the file. So I think if I'm to contribute to the conversation today, I'll say the why is quite important because you find it carries everything. It carries everything. If you don't know the why, then DevOps loses meaning. You can have DevOps in a company, but as long as you don't know where it's going.

Speaker 5: 1:05:45

Those tools are quite a lot, the mention of those. When you talk to someone they know. So you bring them on board. Then they realize, oh, no, okay, okay, where do I plug it in? So it's like you for an engineer who is building an engine. You may give them one screw, okay, and it's a specific size. So they know that screw, they know how to screw, they know how that this goes into a certain hole and I am supposed to turn it clockwise or anticlockwise, to open or close it. However, if they don't know what we are building number one, it's an engine. Number two, the place it's supposed to actually fit then it loses meaning. And that's what I've.

Speaker 5: 1:06:37

That's why I was interested in this. I wanted to know how are people using DevOps in different situations? Okay, not that's the tool. The tools are known, the tools are there, but what is the reason why people are using?

Speaker 5: 1:06:52

Yes, you've talked about automation and, um, there's a part that I'm missing. So there is what we call testing at the end testing, and it's also a major part. So you've automated your deployment process. However, is it serving the end user so I can deploy something wrong? But is there a place where you are identifying in your automation? Identifying is what I've deployed to my client the right thing? Is it even working? Many times, as a developer, I build something. It is worked. I've not even found a failure as I was building my WA file, but then you go and click that button and you realize, oh okay, two hours gone, I have done nothing, so you need to go back and actually do that.

Speaker 5: 1:07:50

So where does that come in? Where now, most people have said they are quality assurance, which now leans more to the DevOps, but I like how you've mentioned it. Developers actually need to know. Devops Mostly has been pushed to the QA, but I would like to know how QA, which now deals with the actual thing, have you deployed the right thing, how it marries into dev, because after I've automated my deployment process I need to confirm is it the right thing? Then I can now offer a solution and I can now measure that my DevOps is something I can work with. One of our core values at Sstec is delighting our customers. So even if I've reduced the time but the product is not working, the client doesn't want to know it's not working. So how do we measure that in DevOps?

Speaker 2: 1:08:46

All right, if I may start, then Edu will do the rest of the part. Let's handle the testing part right. We have the CircleCI, or rather the CI platform that we are using. So for that part, it's automated building, automated testing and automated deployment.

Speaker 2: 1:09:10

Now let's talk about testing, because the key thing here is testing. Now, in terms of testing, as a developer, you do a lot of testing. Number one you do the unit testing, right? Then, if really okay for unit testing, it covers the code coverage you want to account for any line of code you've written. You implemented a button. Is it really working in terms of that code? But when you go and click that button, is it really working?

Speaker 2: 1:09:41

So what do we call that other part of testing, which is now the usability testing? It's called user acceptance testing. So before you give that product to the user or to their client, you do the acceptance testing. So with that, you ensure that, okay, you build, you ship, you run that part where you've built and you've deployed your application. The next thing you're supposed to do is to test and the final part is to validate and for you to test and the final part is to validate and for you to validate. This testing here is not unit testing, it's not those automated tests, it's the acceptance testing and that is the one which is testing the usability of the product you built. So that goes back to the developer, not necessarily the DevOps engineer yeah, the DevOps engineer.

Speaker 5: 1:10:32

Yeah, so what is the role of regression testing and the tools that go into regression testing in terms of correctness of what we are actually deploying, and is it part of DevOps and is it part of DevOps? So in my listenings and the corridors with them, they talk about something called Selenium. Yeah, that one was Achillean. Achillean and tools like those right Are they part of DevOps? Yeah, killian Killian and tools like those right Are they part of DevOps? And are they part of the tools that we need to consider? At the end of the tail end, my deployment is okay, okay, but then because my understanding of DevOps is development and operations and my operations part really touches on the client and I need to ensure that that is delivered- Okay, now still, this is my part.

Speaker 2: 1:11:38

I do it Now in DevOps part. We have the CI CD, right, ci, continuous integration. Okay, when you talk about continuous integration, you are testing that if I've really integrated this code from the previous version that we had, is it really compatible, is it working as it was working initially? That is continuous integration and we are doing that testing using the likes of Selenium and others to test that. Remember, I've said for user quote, unquote, user acceptance tests, that remains independent. Okay, I hope I'm making myself maybe clear, but I want Edu to add on it.

Speaker 3: 1:12:30

So it's something like I can talk, like how I can say what we do here. Currently there is this model we call test-driven development, whereby when the developer is working on their code, so what they do is write test cases test cases which the code must pass before it gets to the deployment phase. So that's it's not DevOps per se, but again, when those test cases are run, it becomes part of DevOps for our case. So for any bit, for any code which is written, it has to go through. The test cases has to be written. First. Emails need to be validated. You need to write a test case with valid emails, invalid emails, by the time it gets to testing. When you are running the test cases, all the tests need to pass before you proceed.

Speaker 2: 1:13:28

Yeah, before you ask, I want to add on that TDD. We all know that TDD are called quote-unquote failing tests Initially. They must fail when we implement what you said. It's the time it passes, right, yeah?

Speaker 4: 1:13:50

Just to add on what you said whoever writes the test case is not the one to do the testing.

Speaker 7: 1:13:57

Yeah, yeah.

Speaker 3: 1:14:00

Because for those cases, whoever writes the test case also writes the code. Then it's going to be got by the code reviews, like I usually do, the code reviews.

Speaker 4: 1:14:16

Whoever is writing the code is not the one to write the test case. That's what I'm saying. Test cases are written separately and then handed over to the dev for them to actually write the algorithm, and all so that now they can test.

Speaker 2: 1:14:32

But in the instance where you are the one building, shipping and running.

Speaker 3: 1:14:40

Yeah, but again like in an ideal situation? Yeah, you shouldn't, like whoever is writing the test In an actual software engineering and development lifecycle. That should be done by one person. Test us Okay.

Speaker 13: 1:14:57

He actually has built on what I wanted to ask From the approach you've taken. It's almost like the operator silos, like DevOps ends here, development ends here, devops here, qa here. But my experience has been sometimes it's hard to differentiate. So if we are to take the distinct or specialist route, tell us how that would look like and if you are to take the model, the sheep, what you have, told us how that looks as well, can we? Just so that we see clearly what the difference is.

Speaker 5: 1:15:36

Okay, just an addition, because sometimes getting the silos is expensive and we want to also know but we would like to know in the silos who are these individual people?

Speaker 2: 1:15:50

Okay, if you look into the very many reasons as to why we have DevOps, one was to eliminate that thing of working in silos. It was to bring about collaboration and to enhance communication. So when you talk about silos now, you kill the essence of DevOps. Yeah, so I don't even think there is a reason to answer that.

Speaker 5: 1:16:13

No, no who is.

Speaker 13: 1:16:14

No, no, the one who said QA or test, sorry, the other one was actually said I was with you until you said now that's no, that's not DevOps anymore. So I was like eh, there's another part that's not DevOps.

Speaker 5: 1:16:32

So the clarity of where does DevOps end. Then there's the testing and then also there's a developer on this other end who gives you who's writing the code and everything. So can the players in that face are they separable.

Speaker 2: 1:16:47

Okay.

Speaker 10: 1:16:50

Kindly, I think, my colleagues, I think they just want to know. They're not really saying silos as per se, but at the end of the day, everyone has their role in an organization, right? So what they really are asking is these are DevOps, here's his role. Then here's the QA here's their role, here's the developer, this is his role. Thank you.

Speaker 9: 1:17:27

I just wanted to sort of disagree with Dennis. I think in TDD the developer has to write the tests in the code before they write the actual code. The functionality that they are trying to implement and the way to eliminate bias is not for someone else to write the code, but more it should be eliminated during code reviews, where someone else actually looks at what they've written and tries to verify whether the tests cover everything that was meant to be covered, whether there is that kind of bias or anything, before they can merge the code into the main repository.

Speaker 4: 1:18:12

The reason as to why I said that is because the most illiterate person is the one who's going to make your system fail. The most illiterate person is the one who's going to make your system fail. Trust you me Talking from experience.

Speaker 9: 1:18:27

Yeah, though I think that is already flawed in essence, I would say, because if there is no way for the code review to catch some of those issues, then the code review itself needs to be reviewed.

Speaker 14: 1:18:45

So I feel there's some truth to both statements and such issues tend to be very opinionated. But ideally, yes, it should be like that. Ideally there should be someone for QA, ideally, the test should be done separately to eliminate bias. But unfortunately we're not in an ideal world. So we try and mitigate the bias. So, just from defining your API schema, you can know what kind of tests they can come, that will come, and throughout your process and your pipeline, you can slowly by slowly, reduce that failure rate more and more so. But the test is one Code review, second by the time it reaches DevOps. Basically, it's just an iteration on top of the other because you're working with what you have at the moment. I definitely agree with both of you.

Speaker 14: 1:19:53

Yours is the Bible truth, but unfortunately we're in the 21st century. So, yeah, so it's just about mitigating that bias. And even if here's the crazy thing even if you had someone do the test case separately, you cannot eliminate bias 100%. I think you can see this, especially when you do a focus group where let's say, for example see this, especially when you do a focus group where, let's say, for example, you had your team, your product team, which did, let's say, ux, you had your developers there. Everyone did their job, but when it came to the client, everything was mother godania. So it's about bringing it to a minimum, but eliminating it completely might not be possible.

Speaker 2: 1:20:59

We've not even answered your previous questions.

Speaker 1: 1:21:01

Exactly, so is the testing matter. You want to answer on the testing matter or the silos, or we're done with that.

Speaker 2: 1:21:11

It was one thing I thought.

Speaker 1: 1:21:15

Okay, you can contribute.

Speaker 2: 1:21:17

Your question was where does DevOps start and end? Now we said, as you've heard my brother here saying, someone is writing code and writing tests as a developer. You test them locally right now on a cicd platform where now the devops engineer has implemented the workflow for doing that is where he, he or she runs the tests, not necessarily running writing the tests, so the test has been written by a developer, but running or executing those tests to ensure that the integration is perfect is the work of a DevOps engineer.

Speaker 2: 1:21:58

Now remember Ben? Ben asked a question how about makefile? Does it contribute to DevOps? Right, I think I have indicated to him yes and showed him how it works. Now, when you think about that makefile, it's in your code repository, written by a DevOps engineer contributing to your code. But, as you've seen it, do you think I was really interacting with the code? Or just some few commands. Just some few commands, right? Not necessarily the ins and outs of that code.

Speaker 2: 1:22:29

So the tests you, as a developer, you are writing. My work as a DevOps engineer is to run those tests and to ensure that they're like, say, you have the threshold for your coverage. You say maybe 90 or 100, the threshold is met. So by me running those tests, not writing the tests, okay, yeah, so when you, okay, we wanted to eliminate that silos in development, so we integrated DevOps. Now, when we have make okay, an example of make in his workflows. So what have I done? I've gotten into his development work and created my workflows inside his work, not necessarily working with his code, or rather adding lines of code to his files. Get my point. So if my work is to test, it's to test, not to write the test, but to test. That's my work, then the other work is maybe to now automate that testing. Answered um.

Speaker 5: 1:23:43

So to build up on the conversation about testing and weight ends, okay. So to build upon the conversation about testing and where it ends, I look at it from a business perspective. I'll look at where the idea is coming from or the error is coming from and who has realized it. Remember, for us to be able to write a test, you must be understanding the logic, the end goal of it. So just to marry the two ideas that came from the gentleman, is that the person who knows the idea, who knows the expected result. So I'll break it down as to how I'll reason it. Number one I'll look is it a new feature and who understands the new feature? If it's a discussed feature, like in my team, I have QAs, I have developers and I have devops and engineers. So if we discuss it as a team and we understand, then I expect the QAs to write the test. Developers then will develop because we understood it. That is for a new feature. We discussed it. So everybody knows. But now, when we're coming to put it to paper, I expect the quality assurance. Who will now come and test it to ensure that it's the right thing that the developers have made? But now it can come in as a new feature that the developer themselves made. But now it can come in as a new feature that the developer themselves has come up with. Probably it's automation, an innovation that they want to bring into the code. So, yes, the developer can write a test unit, a test case, and pass it to the quality assurance and explain the logic behind it. You have to understand. For you to know that the test is failing or passing, you have to understand the end goal. Okay, so in that case then a developer can write, because you're bringing an innovation, not everybody might understand it, but as you explain it, you will write the test. So in my case, I'll still use the tell the developer to work with the quality assurance so that they build the test case together, because my quality assurance team have the standards of writing a test case so that it is measurable. But the developer will eventually have to just come up with a sketch of a test case for that innovation.

Speaker 5: 1:26:02

The third part is the clients. A client complaint or a client feedback who does it reach to, are the first thing, because if a developer writes a test case and has not interacted with the end user, then I'll have problems Because they don't know what the end user wants. But my quality assurance or my customer success team are sitting between who I get and my end users and my developers behind the scenes okay, and my DevOps engineer behind the scenes. So I'll expect my quality assurance based on the interactions between them and the user. They come up with the tests okay, because it is until you understand the end goal so you want to achieve achieve sending of birthday emails. So the test case is ensuring that everybody's birthday.

Speaker 5: 1:26:56

Once it gets there, there's a scheduler that automatically sends. All that will be. The QA will understand and it is the work of the QA to transmit the test case to the developer. Developer writes whatever they're supposed to write and pushes it back. And after the DevOps.

Speaker 5: 1:27:14

Now, when you see the UAT, it's a question I wanted to ask is it automated? Because the UAT is on the client side, but on our end, how do we then ensure that there's regression testing, but of a new feature? I think there will be manual testing, which is also part of regression, however. So when the developer sends it back, it's the QA, now who understands the end goal of the user, who tests For a new feature. After the developer has done everything. They will sit down with the QA and actually do the writing For something we've discussed in-house.

Speaker 5: 1:27:47

Then the quality assurance team bear the responsibility of actually ensuring the end goal is met. So, when I look at, when I'm answering, the question of who has to write the test cases is who understands the end goal better? Okay, depending on where we are. Okay, I think, on the separation, I think the people who work with the end user, so they'll get the feedback. So that's a quality assurance. Who will do the testing? Then we have the work of the DevOps engineer and the developer. How they marry into each other is then a kogmaya. Where does it end? So that? And the quality assurance are they the DevOps? Are they in charge? The quality assurance? Are they the DevOps? Are they in charge of the development and the DevOps process? Then how then do they marry In-house? How does it marry?

Speaker 11: 1:28:39

So I hope your story.

Speaker 1: 1:28:48

An addition before you respond Anyone else with additions.

Speaker 11: 1:28:56

So I think we've talked about automation before talking about the factors we need to consider before we automate, because I don't think we need to automate something that can be tested once or that functional testing can do that. Yeah, please can you pardon. I'm saying we've jumped into automation without considering the factors that we need to maybe consider first before we automate. We just can't automate all the features. Say, it's something that can be tested once and that is it Maybe to answer that, sorry.

Speaker 2: 1:29:41

In a nutshell, though, this is software development. It's a life cycle, it's continuous, it's iterative, so you can never test once, or am I wrong? You can never test once? Say it's continuous, iteratively, so you can never test once, or am I wrong? Can never test?

Speaker 11: 1:29:52

once say it's. Uh, it's a feature that's not don't need. Uh, maybe it doesn't change like say you will only do say test once and when that is done it's, and when that is done it's.

Speaker 9: 1:30:09

Really I think for that one, like I also.

Speaker 3: 1:30:14

For such a feature, like it becomes like a part of the service, like which you are offering, and for that one, like you need to have like the test somewhere. So like I think, like you need to automate.

Speaker 11: 1:30:25

Say also we also need to consider maybe the risk, the risks that feature has because you just can't automate. Maybe you need to pick the features that has a lot of recent automate, like it has a lot of importance.

Speaker 2: 1:30:48

So maybe you'll match on that I wanted to say.

Speaker 9: 1:30:58

even if it's a feature that doesn't change. I think that's one of the reasons you have to have tests for it as well, automated tests, so that even when you're touching on another aspect of another part of the system that might not, in your view, affect this part just to make sure that it has not affected it then the automated tests need to be run to just make sure that feature still works as expected. So that's why you would need to even have automated tests, even for those specific features that don't change.

Speaker 2: 1:31:30

Yeah, Also, maybe to add on, that when you use a tool like Sarkozy I don't know of others, not rather Sarkozy, but Ansible playbooks they are referred to as idempotent. This means that if this is the same, these are the results you got this time and you never changed anything they should be the same result you get the next time you run that command, or maybe you run that file again. So even if you write tests and you automate them, nothing will change because it's idempotent. Okay.

Speaker 4: 1:32:11

Just once or not to answer his question. Tests are automated to avoid happy testing. Most devs what they do is happy test, just cross the keyboard and then just to advance on that. So now people are moving to the new model of the ML whereby you do supervised and unsupervised. So once you write your model you can train it. So now it will run through the whole system, whether you add a small component to one module or something of the sort.

Speaker 8: 1:32:56

All right Any additions on that question before we move to another one Perfect of a topic on DevOps. There's the emerging trend of security that is integrating security into the whole DevOps process. So, for example, in our instance we call it DevSecOps. So I would like maybe more discussion into that and tools for that process.

Speaker 3: 1:33:32

yeah, Actually, I would say that currently it's like security it's a function. It becomes among the main features of a system. Actually, it's something we can discuss more on that. Yeah, it becomes among the main features of our system.

Speaker 2: 1:33:53

Actually it's something we can discuss more on that. Yeah, so maybe when you talk of that DevSecOps you talk about now the security is shifting to the left, right. What do I mean by that? Okay, before you ask the question, let me just build on that. Then you can ask Okay, please, so think here we are now integrating developers and operations into one to ensure that all the processes are running from the very beginning to the end, end to end.

Speaker 2: 1:34:22

Okay, now why not bring the aspect of security in here now to run from the very beginning to the end? Because when you put the security at the from the very beginning to the end, because when you put the security at the end, you are at risk. Remember, when you are building your applications, you have the libraries that you are using. Now the hackers nowadays are going to the next level. Instead of now attacking directly your application, they are attacking the library that you've used. So think of that. So if you have ensured that you implemented security from the very beginning, it means that you've covered that, that block so actually, what you have said is what I meant.

Speaker 8: 1:35:06

Actually, what you have said is what I meant, sorry, sorry. So what you have said is what I meant. That is, integrating security from the first step, that is, the development building up to deployment. For instance, in the development point we can for instance something like static analysis and stuff like that. That's what I meant.

Speaker 5: 1:35:39

What he's trying to say is from your knowledge and experience, can you guide on how in the DevOps, how can we integrate, and are there tools that you can suggest? Okay, that we can use in line of that? You know we have SonarQube and SonarLint OASU. Oasu is a measure of the first 10. But, yes, some of the tools that you say I liked how you say doc, doc, a hub, docker, composer, those are the best, but then for different people can offer different. So how, what are the tools that you found in the industry that can really aid in those who would like to know that?

Speaker 2: 1:36:30

Yeah, all right, now one before I answer, before you roast me, I'm not a DevSecOps engineer. Okay, I'm a DevOps engineer, but I think I can handle it a bit of it. Now, just basically the way you see it from. Okay, if I may put it like this, when you are building or writing your code, you have your version-controlled environment, right, Like GitHub. Let me talk about GitHub. Have you seen this thing called GitHub bots, saying the security bot, this dependency has gone to this and that? So what is that? Dependency, vulnerability checking, right? Yeah, so it is scanning the versions that you're using for your dependencies. So that's one scanning your dependencies, definitely, maybe using the version-controlled environment you are using. Others are like tools offered by organizations like Aikido, c-snek, right, those tools, remember, I said I'm not a DevSecOps. Maybe he can answer.

Speaker 3: 1:37:40

I'm also not a very big, I haven't worked Okay, I'm also not a DevSecOps. But again, another thing we can add that like is like the use of secret management tools. Let's say like something like VOTE, so that, like, you don't need to store, let's say like your secrets or your passwords, like in the configuration files. So other things like the image scanning, like whenever, like, an image is pushed to GCR or like to your registry, it needs to be scanned for vulnerabilities, at least like. And then, adding to that, I'll also say like using best practices, let's say things like code reviews. Actually, I'll consider them as part of security in such a way because, again, you are able to catch or eliminate bad code or bad quality code. So I would say like. So, with proper implementation of DevOps, I think most of the security will be captured at that layer, but to add or to kill it.

Speaker 2: 1:38:43

remember there is DevOps and DevSecOps. Please, two different topics.

Speaker 9: 1:38:59

Ah noted noted.

Speaker 1: 1:39:01

Oh so security Noted. It's going into our bucket list. Cto roundtable bucket list. Security has been added. Good point Anyone?

Speaker 12: 1:39:18

I think just an addition to your question. You can look into a tool called Snyk. It's S-Y-N-K. I heard about it in a podcast. It does security analysis of containers libraries, so you can get at least a bit of security detail about your application from it. Synk, snk yeah, synk.

Speaker 11: 1:39:44

SNK. Oh, snk, snk, you're using that too, Okay, sneak Also add.

Speaker 2: 1:39:57

Aikido into that what you have said, aikido, aikido, a-i-k-i-d-o. Aikido For repository scanning.

Speaker 1: 1:40:11

Aikido For repository scanning Aikido sneak.

Speaker 10: 1:40:40

Okay, what I wanted to request was see, I know everyone that has come here. They came because maybe there's a way they are implementing some of the implementations and they would like to get a bit of inputs here and here to add on to whatever they are doing right. So, with that, I'll just request as a last thing, maybe before we close you are a DevOps engineer just take one project that you ran with end to end, the shortest if possible, and just walk us through technically okay, a project that involved DevOps, end-to-end right Okay.

Speaker 2: 1:41:35

So I have a very small one here. You know why I'm saying that.

Speaker 13: 1:41:44

Yeah, yeah.

Speaker 2: 1:41:45

Today there is an event happening called Nairobi Innovate right. That is what I presented, so if I present here, it will be here. But let's show it. Yeah, so let's open it.

Speaker 13: 1:42:05

Two presentations in a day.

Speaker 2: 1:42:08

Thank you presentations end to end of the day, yeah, so in this small project here, I'll talk about this small thing, what I did to achieve maybe DevOps in it, All right. So we talked about Docker, right? Sorry, sorry, sorry, sorry. You know what I'm talking about. Okay, so we've talked about Docker, circleci, docker, compose and Ansible, right, those are the tools to so, if we do something here, or maybe to highlight what we have starting from Docker. So this is Docker very simple, simple thing. But I would like to maybe show another one. Now we have. This is Docker very simple, simple thing, but I would like to maybe show another one. Now we have. This is simple, like straightforward, right? Then, okay, if you understand Docker, how to write a Docker file and I said that this one is like a very basic thing you are just deploying one container, or maybe two containers, maybe a backend and a database, right. But now, in a case where you have a frontend, a backend and a database, you also know that maybe you'll need other services, like, say, the Redis server. You'll need maybe RabbitMQ, right, when I realize I'll be too right, yeah, so for that, it means that you'll need to have a multi-stage Docker file, you understand? Okay, let's see if we have it here. Okay, yeah, so something like this, not into details, though. Like we are saying, we have stage one and we have stage two. Why would we want to have such a thing?

Speaker 2: 1:46:14

Now, the first bit here is where we are now building. We want to get the artifacts for a JavaScript framework, say Angular React. Now here we are using Vuejs, so we are building the artifacts for Vuejs. Then, on the next end, now you ask yourself how do I want to serve this application? What web server will I be using? Will I be using Nginx or maybe Apache 2? So, for me, I love Nginx. So this bit here is when I configure Nginx in my Docker file and, as you can see, also getting the image from Docker Hub and running all the configurations for Nginx. Now you see, what we are necessarily copying is the nginxconf or the configuration for Nginx. Yeah, so something like this If you've configured Nginx in your applications, you know how it happens, so it's just as basic as this.

Speaker 2: 1:47:16

If you've configured NGINX in your applications, you know how it happens, so it's just as basic as this. I don't know what to mention. Yeah, so we have these multi-builds or multi-stage building of Docker images to ensure that whatever you've built is an image here fronted in a corner. It's bundles and the reverse proxy server, right, yeah, so that was not the case. So we have a very basic Docker file here. Then the next thing we talked about was Docker Compose. As you can see again, it's just one service. In fact, we don't even have a database. This means that we are using SQLite. We have a very basic one here To that point. That is Docker. The next part, or the very first part we are supposed to talk about, is the infra how we provision our infrastructure in cloud.

Speaker 2: 1:48:22

So we have Ansible. This one is, I would say it's very complex. It is supposed to be running on AWS, so as you can see from here. So we said Ansible uses tasks and inventory. I said that, did I say that? I said, okay, ansible uses playbooks and inventory. Inventory is the set of hosts to which we'll deploy our application.

Speaker 2: 1:48:58

Now you can see the syntax for this YAML file, just these three hyphens up there For Ansible. It must have those, or rather the YAML. It's written. That is how you differentiate between YAML and TOM. So we have that In here.

Speaker 2: 1:49:18

Don't worry about this. I'm either supposed to say all or other. So we have that this bit here. We said for security purposes, you are not supposed to push your environmental variables to your version environment from here. So you see, we have some variable files here. We have secrets and other configurations, so I just called them everything. We have them here. So, as you can see, they have so many configurations here which are very critical not to be exposed Right down here again for secrets. So back here so you manage them using this parameter here VALS files.

Speaker 2: 1:50:12

Then, on the tasks, you see what we are doing. We are creating a VPC. So so, in short, whatever I'm doing here or the application that I deploy is not on a server, so I will not be using ec2 instance to do that. I'll be deploying these on forget for service. Okay, yeah, so this is the file here. Yeah, so, and, by the way, it's public in my repository. You can get it and if you have a question, you can just ask once. So you've seen that to that end. Yeah, so we all know it's very expensive to have an aws account, so I don't have one as of now because I do use google.

Speaker 2: 1:51:12

Now, the next thing that I want us to look, we have that Now for that playbook, this one here. It will do all the work of ensuring that to where or the place where we want to host our application is already provisioned with all the necessary resources. Like you've seen here, we have the SIDA block for the, the ips, the routing tables, all those configured, the vpc in aws. You have the cedar block, you have everything, all those things in networking, right? Yeah, so these are the things that I'm doing. Then, in this bit, you see, we are using ECR for our image registry. We are not using Docker Hub and again, you know these things KwaNya Muna Tumea AWS for authentication, the key ID and access key, Then other things which contribute to versioning, that is, tagging your image, then setting up the ECS clusters and, as I said, in this we are using Fargate. Yeah, admission, now, if I may, we'll look at another one here. Now, on this one, I want us to look at Docker Compose here. Sorry, ansible, ansible Fargate For hosting images, or rather for deploying Docker images.

Speaker 3: 1:53:09

Sorry, f-a-r-g-a-t-e, r-g-a-t-e, this one Fargate.

Speaker 2: 1:53:16

Yeah, it's on AWS.

Speaker 3: 1:53:18

You have this service ECS. Basically it runs continuous, like it's where it runs continuous without necessarily requiring a Polen.

Speaker 2: 1:53:28

Ok, yeah, fagit.

Speaker 3: 1:53:31

So the legacy is it's your money.

Speaker 2: 1:53:33

Oh, we don't have workers. Ok, okay, yeah, so I want us to look at this Docker compose file here, because it's not working well, so maybe it doesn't make sense. So what do we have here? We have a DB, a database definition. We are using Postgres and its configurations. This is a very bad configuration, right? Very bad.

Speaker 2: 1:54:05

Yeah, so it's a very bad one, because I'm supposed to either be commenting this thing here but presentation to this bit here, right, or I'm not using this, using this bit here. But now, what got to know could happen. You reference them as variables, right, maybe quick, maybe env in H2O2. Right, that way? Yeah, so that is for database. Now, one thing you also need to understand when it comes to Docker Compose or Docker, you have this thing the volumes. Now, that bit of security, you can mostly manage it in Docker Compose using networks, this kind of a network in the Docker Compose Internal only and internet, right, using the bridge. Yeah, so the networks. Then we have this bit here where we have the web and, as you can see, so if I remove this bit here because it's unnecessary, I'm using an env file. So a env for that and the volumes. Then also, one thing you should note is that if you want to protect or to get that security layer in your application in Docker, docker Compose, you're not supposed to be using ports. If you have networks, you can see for many they are commented out, right, so we're not supposed to be using ports. But again, when starting it's good to be using them when starting, though, then we have this bit here where we have depends on. If we are not using depends on, what do we use? Yeah, exactly links. Then you can see I'm using Cloudflare, so my domain names are populated by Cloudflare. So my domain names are populated by Cloudflare. We know Cloudflare gives you a domain name which is SSL secured, right? So the reason that's why I'm using it. So if I was not using Cloudflare in my playbook here, you would see me using let's Encrypt. We use let's Encrypt out here, right, yeah, so I don't have that because I have Cloudflare. Then the rest of this bit is where we define them, the networks and the volumes, right, I think that was large enough to maybe showcase how a Docker file or a Docker Compose file should look like, right, yeah, but Pinafa and other services, as we said, like Redis, inafa, if we want to see it edge, okay, yeah.

Speaker 2: 1:57:13

So back to my thing here, this one, the one with Fargate. So now, that was Ansible. Now, if we look at this, this one, I was deploying it on a Fargate service, or rather a serverless. Now for this one, we have a playbook here. This one, you see, I'm using GCP, right? So I'm not using AWS. So what am I using in this one? So in this I'm using a Google VM instance, which is an alternative of EC2 instance, right? So you can see here it's different from the other one. The other one had a lot of lines, this one has just 109. And what am I even doing in this one? These ones are almost unnecessary.

Speaker 2: 1:58:11

But now, from here you see, it's the very basic things you do when you have your new operating system, that is, your new OS on Linux, right? You update, upgrade and install the dependencies that you need. Remember, we said Linux is based in Python, right? I think I said that. So you see, we'll be installing a lot of Python-based dependencies, which we have here, python-based dependencies which we have here. Then, because whatever I want to deploy is a Django application, this means that I have to install Docker in my server. So you can see the first things that you do when installing Docker in your machine. So you add the GPG keys, you add the repository, that is, the apt repository, then you install Docker and Docker Compose, but for you to install both, you still have to install Docker CE. That is the community edition, right? Yeah, then from there we know when we just install Docker in Asuboanga, it has to say, like permission denied, you have to run as sudo. So to eliminate that issue, you run this thing here by adding Docker to your user group, so you'll just be executing Docker commands without having to escalate your privileges. Then these are other things that happens on that server that you created, that is the Google VM instance. You need to be having a folder that maybe you want to be interacting with, you want to own it, okay, we know the Linux file system, ownership and permissions, right, so we have to ensure we have that.

Speaker 2: 1:59:57

Then this bit here we said Ansible uses SSH keys. So you have to then get between you, that is, your local machine, the remote server, and remember we have version controlled our, our project. So we are using, using GitHub. You know most of us use GitHub and SSH configured with it, right? So you have to let Ansible know whatever we want to pull from GitHub should also be using our SSH key which we are using or we have configured. Then the next thing is to pull that project from GitHub to a remote repository, remote directory that you created, this one here which you created, and own it recursively, okay, yeah, so you see, here in this bit here for Git. It has a lot of parameters. We have version. Remember, in a good software development approach we use branching right, we don't push to main, but we usually maybe what we take into prod is the main branch. So the reason as to why we have this version here is to specify the version as to which we want to deploy. Maybe we wanted to deploy dev, so we would be having dev here. So any other branch that you want to deploy, then this part here, if you are using Ansible, maybe you understand this bit here.

Speaker 2: 2:01:32

Update, yes, you see, you do an update. Okay, sorry to say this, kuna watu nakua. Primitive unawana code kwa machine. Ni mekata ku run una fuguwa github remote na una editia pale. You see that, okay, ni me sema primitive, get me right, primitive. So with this command here, when you run the command, when you execute your playbook, it it will update, it will take the changes that are there and the changes that are local. Okay, then this other bit here accept the host key, that is, if you have. Okay, like, for instance, we don't have the ansiblecfg which has those configurations, so we have to add it here. Another primitive behavior for me here.

Speaker 2: 2:02:22

Then, as we said, the env is not supposed to be pushed to a version-controlled environment. And remember, whatever we are deploying, we are getting it from a version-controlled environment, right? So what do we do then? And we have a env file that we need. We need it on the remote server. So we use this capability with Ansible for copying. So we are copying our env file from our local machine to the remote server. But remember the way you do your secret management. We also alter this part here. Maybe you are pulling your configurations from one password, maybe from the Google secret management, etc.

Speaker 2: 2:03:10

Then this little bit here for logs, not very important, because I think Docker Compose has its own logging system, so you just query it. Then, once all that is done this is another basic thing that you do when you finish installing Docker, you ensure that it's running. Then another thing, which again very basic when building, or rather executing your Docker Compose so it's just Docker Compose app or build. If you are building your images, as you can see here, this last part here you want to remove any offhand builds that you had Then up. Here is where you now execute it. Or you say docker-compose-app, but in a detached mode. So in a detached mode it will run silently. Yeah, background.

Speaker 2: 2:04:13

Then this other bit here Okay, maybe I'm also a backend developer, so I write Django and this bit here will do some of the magics the migration, the migration to see magic. So that is, in a nutshell, our Ansible playbook. So now another thing that I talked about. I said Ansible works with playbooks and inventory. So an inventory, I said it's a list of hosts, like now here we have an IP address for a VM instance that I have which is running remotely Okay and yeah, so to that point I think I've explained also which is running remotely Okay. So to that point I think I've explained or shown you the Docker, docker, compose, ansible and inventory.

Speaker 2: 2:05:06

So the last bit before I execute that playbook is the CircleCI now, where we handle all that, the building of that docker image continuously, where we run those configuration, or rather executing the playbook continuously and maybe doing the tests continuously. Now this is circle CI. Let me see if I can open one here. So this is how CircleCI looks like when you integrate it with your GitHub. All these are my projects or my repositories that I have. Some are configured like this one is configured, this one is configured, amongst others. Now the one that right now we are talking about right now is called String Reverse API Up here. We have string reverse API up here, which is not set up already. Now what do we do to set it up? For us to set it up, we should be having this file here, the configyaml for Saco CI with the jobs, or rather we have the executors here, and you realize that Sarkozy uses docker. So you see, it's using docker images. Yeah, so we have a variable here which I named as image name. You will see where we will use it.

Speaker 2: 2:06:50

Now the next thing is the jobs that will be doing. Doing the job number one that we'll do is to build, that is, to build a Docker image. So what will we do in this one? Now, you see, these are the normal things when you have a new project, on a Django project, you ensure that you have a virtual environment, you ensure that it's activated, you ensure that PIP is at the newest version, you install the requirements, that is, the project-wise requirements. Maybe you run the migrations. Then the next thing is to set up this thing here, to set up the remote Docker. So you just add that Docker layer caching to true. Then it's now to build a Docker image.

Speaker 2: 2:07:37

This is a common command, docker build hyphen. I'll not go around this bit fast, but we have docker build and that dot right to say that we are building on the current working directory using the current. We are building on the current working directory using the current docker file in that current working directory. Let me find a repetition? Yes, so we have this. Now, when you use this, the hyphen t, that is, this flag we mean that you want to target with either a version Okay, we have versioning Time stamps.

Speaker 2: 2:08:22

All right, that is the date version. Okay, so the commonly used type of versioning is called semantic versioning, right, yeah, there's that one. You said Not, unless you've read something. So we have semantic version. This is where we have maybe 1.0.1. Those numbers are major, main and patch, so that's the most common one.

Speaker 2: 2:09:06

Now, when you want to tag your image mostly in a image, you see, when pulling images, we say latest, most of the times. Right, most of the times, not always, but most of the times. So the latest tag, or you can create your own custom versioning, which is now, following that, the type of versioning that you said you want to use either date or the semantic one. Now, for me. I love semantic and you'll see in a bit how.

Speaker 2: 2:09:35

So, after building this Docker image and tag it now for tagging, let's go to where we are now building that thing for tagging. We have here, do this, okay, let's see where we are tagging, or pushing, publish, tag. Now what are we using to tag? You see, like the image tag, it will come in this approach. But now, if we come here, you see how I have defined it that it will take 0.0. The number of builds that I have in CircleCI. So for my first build, I have 0.0. The number of builds that I have in CircleCI. So for my first build, I have 0.0.1. If I have 100 builds, I'll have 0.0 points. Yeah, now, this is the repository, that is the image that I built and this one.

Speaker 2: 2:10:35

If you come to the tags, you'll see here we have latest and we have a version number right which is 0.0.41. So the reason as to why all the reason, there are very many reasons of having this approach is, say, the latest version has failed. How will you roll back to the previous version if, say, you do not have the number one? See, you will not have a specific version to go in Now, like if the latest version fails. I know it's the version 0.0.41 that failed, so I'll have to go back to 0.0.39, right? Yeah, so this is how we build that and we manage versioning in docker. So we were at this point for building and tagging that image. So the next thing that we'll do not not very necessarily this one, but remember, we can build images which are very dense Like you see, it's 2GB of an image.

Speaker 2: 2:11:43

What we do maybe now is to archive it or to compress it into a tower or a zip. Then we archive it on Docker, or rather Docker Hub, and this is the command for that and the path. You're just defining them here in this configuration file. Now the next thing is to deploy this now, to deploy our Docker image or Docker containers on our EC2. Now, remember this project I was following the EC2 approach. That is for AWS, so we had this where we now run this one. The main reason for running this is because we want Ansible to be installed in our virtual machine here. Okay, so we'll act like our virtual machine for the moment and we want Ansible to be installed for it to run. Now, ansible is in these requirements, then, if it's there, this command we run.

Speaker 2: 2:12:46

Okay, I hope you can hear this bit, this bit, it's command. Then pipe. The output of this command is the input of this command, right, easy, easy, easy. The output of this command is the input of this command, right. Then we have this bit here where we now like publish the latest image or the latest build that we have. This just makes sense. But now to this point here I have to docker push. But remember, for you to push you first have to log in, right, and CircleCI manages your secrets. So you can see, here we don't have I've not like written them down or exposed them they are managed by the environmental variables in circle ci. Maybe if you do some more research you'll see that. Yeah, so you docker login, then you docker tag using the latest tag and the image tag, this thing here. Then after tagging we push. Now see, I'm pushing both the latest and that with the image tag, which now will come with a number. Okay, now I think I should do this bit here which will be used to create or to build those tags and publish them. Then we have this last bit here.

Speaker 2: 2:14:00

Now, this is the most important one in this Sarkozy configuration. Now, what we'll do. Now the workflows. The first one will be build on main. The jobs will be build and we are saying filter On which branch do we want to do the build? Only the main. Then we want to publish the latest. This one now requires build. But remember, for us to publish we have to build. So it will require build and definitely it will have to filter on main. Now we have this configuration up here and the project is already on GitHub. So if we come back here to Sago CI, we have this project and say setup, then it's on this, on that. Then it says found on this. So it says it already found a configyaml file in my repository. So I just set up.

Speaker 2: 2:15:04

Yeah remember what this configuration will be doing. It will be building an image that is a Docker image, publish it on Docker Hub, then run an Ansible playbook to deploy it on ECR. But I said we don't have an ECR, so what will we do? We'll go back to where we have something that can work for us for the moment. So we have a playbook here which I said it's for GCP with all the configurations. So what will we be doing? This is what we'll be doing. From this playbook, we run our Docker Compose, which will now build our images Right here in this one. We are not publishing images on Docker Hub. We are building them on the go and running them on the go. Okay, yeah. So we saw this and our Docker Compose says it's built. You can see we are at every stage, apart from the database. We are building right. At every stage, apart from the database, we are building right, yeah. So if I execute these, let's come back here. That is just activating my virtual environment. Now we have to ensure that we have Ansible installed. So, yeah, it's installed. So, yeah, it's installed. So the next thing is to execute it.

Speaker 2: 2:17:03

Ansible playbook Ansible playbook hyphen. I hosts. These are called the Ansible ad hoc commands. I think you should look at them. Then we execute that playbook. So if, if the connection between my SSH, it's, it's connected SSH because we said Ansible uses SSH, yeah, and you can see it's deploying on this, it's deploying on that VM instance, if we say and that IP address, yeah, see, we are in that server, okay yeah. So yeah, now, whatever I'm deploying, it will come here because I already deployed it. Okay yeah, then it can deploy. It's still working In a far faculty access here yeah, we said we are using Cloudflare.

Speaker 12: 2:19:10

So to go to Marisa access, I think he'll come with you. So if you have questions before Marisa, I have a question. You mentioned ansible is build on Python. I expected it to be like Python code and not YAML. Can you do Ansible in Python code and less YAML?

Speaker 2: 2:19:20

A question. A question Not because Linux is based in Python. Do you have a Python code?

Speaker 12: 2:19:32

No, but because I've interacted with Plumi and Plumi will write very little Yarmul.

Speaker 2: 2:19:39

I said Plumi is language and urbanistic right. Okay.

Speaker 3: 2:19:57

Any other questions it's not exactly, but it looks like it. It's like a crystal If you're caught in here. If you're caught in here, it becomes a crystal. It's always a familiar environment, I see.

Speaker 2: 2:20:30

Question before we end the live. Or when I was answering, did you answer?

Speaker 5: 2:20:44

Were you content? Yes, we are contented. I think it goes back to the comment that I made earlier that when you were explaining it is when you did the Docker Hub, docker Docker Composer, then you had a Docker Hub, then Cloud CI, then Git, then you had Ansible down there. It's easy and very many people know that language. And it's easy when you, even After we go through these is when now you appreciate, and that's why I appreciate what he does. So that's why I say it's difficult at face value to actually say that someone is good, especially for people as CTOs. You find someone who really knows the jungles and can really speak a lot of DevOps, has quite a lot of lingual artifacts, you can say quite a lot of things, but you'll realize that then when you go to the, the gist of it, then we need to be able to understand the flow. So the items you've mentioned that are quite, quite relatable at a city or level that number one you've shown the security part of it by ensuring and there's an environment file that is separate You've showcased that there are different elements and different files for actually building different items before the deployment, because for the longest time we were just dealing with the code. As long as you can do Marvin Clean Compile, that was it. But from what now we're getting from this is there's no more. And that's what I was afraid of, that I come and listen to a session that tells me what I know, because from a research perspective, I know quite a lot of jargons and what they mean. I don't know how I got to learn ML or ops, but I at least knew something. I don't know, but at least I know it's somewhere in there. But now, when you go into the gist of ML it wasn't for discussion today, but if we now go to the gist of ML, I would like to know, as a CTO, how then do I get to measure my team and their knowledge of these? And that's what internally we are developing something of that sort where we do not get someone who talks. In fact we just do a silent interview. Give you a paper there, we give you code, tell you this is the repo, do something about Docker. You say you know. So at the end of the day, we want to see at least build a pipeline. Okay, we'll install the necessary, but at least build a pipeline. We'll tell you Docker is installed and everything, but can you come up with something like that?

Speaker 5: 2:23:46

Because most of the people in the industry and people who say they're quality assurance slash DevOps engineers. They lack the qualities, as you say. The qualities and your emphasis was in really good people who actually know what they're doing and, to get to the level that you do, at least you have a clear understanding of what really is known. So I think this last part has really informed the decision of how to build a successful team. How then, do I get to know from the language you understand the language, so that is okay Then do you understand the actual workings that go into place and can you separate the two? And then, with the whole conversation that was going, who writes unit tests and who right the test cases and everything. Then, when you, when I Get out of here, I think I'll go and sit down and marry all the ideas that we've spoken to and that that, to me, speaks, speaks a lot about what I wanted to achieve for today.

Speaker 2: 2:24:50

Alright, I hope I helped and happy if I did.

Speaker 1: 2:24:56

Great feedback. I helped and happy if I did. That's great feedback.

Speaker 9: 2:25:03

Yeah, there's something you mentioned somewhere at the beginning about DevOps engineers not being paid well in Kenya. So what do you think is the range, or a good range for a DevOps engineer?

Speaker 2: 2:25:17

So what do you think is the range or a good range for DevOps engineer? So for the range, we definitely have to talk about entry levels, or rather the seniority levels, before you start talking about the range. So let's say, a mid-level DevOps engineer, if you are going for an interview, let me just start there. Or rather you've interviewed for DevOps engineer, you know where to go and check for the right salary range and that is Glassdoor and Paycheck. I'm not the right person to answer that. But if I was to say I'm mid-level, what would determine my mid-level? The number of years I have?

Speaker 9: 2:26:14

Probably number of years experience.

Speaker 2: 2:26:20

Let's say what? Three to five years of experience. So if it's me who is asking for that salary anything less than 450K it's a no-go zone.

Speaker 9: 2:26:31

That's gross or not? Gross. Okay, yeah.

Speaker 5: 2:26:42

On the question of how much is paid from a business perspective, you come in, do not tell me what to pay you. Okay, I'll see the value from what you give. And that's what I'm saying. I cannot take someone Right now. You're taking someone and you're giving them the amount of money that they're requesting because they've gone and checked and from my end I've gone and checked, I know they're not paying this much.

Speaker 5: 2:27:07

But when it comes to their work, personally, I'll say, first of all, from a CTO's perspective, I'll not base your salary on what you tell me. I'll be, show me the work, then I'll bump it up as long as I can get value. And that's why I was saying the why is the? Why the company and the strategy of a company will build on the why of why we need DevOps. Okay, as long as we can see satisfaction of that, then we can match what you're coming up with. But before we actually get that realization, automation, ease of deployment, as he has done as long as we can get that, then we can be able to talk about that.

Speaker 5: 2:28:00

But in terms of payment, in the industry, most people know the lingual but don't know the actual working. So very few people know the working and for those they're priceless. So for those I'll appreciate that. They're usually good, they get you where you want to go, and the best thing about a good car is once it gets you where you can count on that car, and so that becomes priceless. So you can actually pay more than even the industry standards if someone is getting the value. That's how I would answer.

Speaker 2: 2:28:35

Okay, a quick question question he got out of mike, mike now, let's assume I was doing an interview. This one was an interview. How much can you pay me?

Speaker 5: 2:28:47

I'll not answer that okay, fair enough.

Speaker 2: 2:28:54

yeah, thank you, guys. Guys, that was me. I think I showcased what you wanted, not unless we have any other questions.

Speaker 13: 2:29:06

We have comments Ending. Thank you so much, and I usually, as you said, we appreciate when someone is not just talking, they actually walk the talk. So good work, man Kudos. Thank you, thank you, thank you, thank you, and now a big round of applause.

Speaker 1: 2:29:38

Thank you, Joseph. This has been a very insightful session Educators, informatics and very important. Thank you to the great audience. We are pushing the right buttons. We want to know. Sharing amongst yourselves that conversation is highly encouraged. We really do appreciate that. Thank you so much for spending the time to be here and with that we will end and conclude their works for today, Looking forward to seeing you guys in the coming ones. So, from Africa, Stalking and myself, Sylvia, thank you and have a good night. Thank you, Amen.