My name is Ricardo Castro, and today we're going to talk about CI CD and build deploy automation. Let me start by thanking the organization for accepting my talk, and let's get on with it. So what do we have on the menu for today? So we're going to briefly talk about CI CD. What is CI? What is CD? We're going to talk about regular development workflow and what are some of the alternatives that we can find to actually employ CI CD within our organizations. Before I leave you, I will say, what's the problem with all of this and why I'm talking about this topic? And I will leave you guys with some reading material. If I was in front of you, I would ask the following question, who here is practicing CICD? And a lot of people will probably say, I am practicing CICD, but let's think a little bit about it and let's see if we are really doing CI CD or if we are only having build and deploy automation. Let's start from the beginning. What is CI? So according to Grady Brochure, CI is the practice of merging all the developers working copies to a shared mainline. Also, we can go into the Reddit definition and saying that a successful CI means that new code changes to an app are regularly built, tested and merged to a shared repository. It is a solution to the problem of having too many branches of an app in development at once that might conflict with another. And of course, my favorite one is from Dave Farley. So CI, it's the idea that we can do a better job if we maintain a clear picture of how changes work alongside everyone else as they progress. So why do we need CI? So we need CI to reduce risks. So when we introduce changes, we want those changes to be less risky as possible, when to decrease the number of bugs. So if we introduce less changes, we, in theory, have less bugs. Also, we want to minimize the integration issues. So if we have smaller changes, it means that those changes won't have as many integration issues as they could have with bigger changes. And of course, it's a precursor to CD CD meaning continuous delivery. So what is CD? CD can stand for continuous deployment or continuous delivery, and it's a software engineering approach in which software functionalities are delivered frequently. Again, I'll resort to Dave Farley and his definition of continuous delivery. So continuous delivery is the ability to get changes of all types that could include features, configuration changes, bug fixes or experiments into production or into the hands of our users. And that intends to be done safely and in a quick and sustainable way. So why do we need CD? So we want low risk releases. So by deploying frequently and putting frequently changes in front of our users, we have lower risk releases. We want fastest time to market, so we want to release features and want to release changes as fast as possible. By releasing smaller releases and more frequently we would achieve higher quality because we are continuously delivering and iterating. And of course we also incur in lower costs, better products and overall happier teams. So bundling this all together, what is CI CD again? Dave Farley how we build better software faster. But we can also resort to other definitions, for example from red app. So CI CD is a methodology to frequently deliver apps to customers by introducing automation into the stages of app development. Or we can go to the knowledge of all the Internet, which is Wikipedia. So in software engineering, CI CD is the combined practices of continuous integration and more often continuous delivery, and less often continuous deployment. Some people distinguish between continuous delivery, a continuous deployment. So let's go from the start. So continuous integration, frequently merging several small changes into a main branch. So continuous delivery, it's when teams produce software in short cycles with high speed and frequency, so that reliable software can be released at any time and with a simple and repeatable deployment process when deciding to deploy. And continuous deployment is when software functionality is rolled out completely automatically. In practice, some people use continuous delivery and continuous deployment interchangeably. But the idea here, if you were to separate between continuous delivery and continuous deployment, it means that continuous integration, you build your software, you test it, and you merge that into some form of main branch. With continuous delivery, you get into a point that the software is ready to be put in front of users. And continuous deployment is the process where you actually put software in front of your users. In practice, what does that mean? CI CD. So CI CD, there's not a strict rule, but as a rule of thumb, we should do CI CD at least once per day. This means that we should integrate code at least daily from all developers on a team, and it should be put in front of users at least daily. So Dave Farley says that CI, for example, should run under 5 minutes. So your CI process should run whatever it is, should run under 5 minutes. Charity major says that your whole process for CI CD should run under 15 minutes. And according to the door report, elite performers perform Cit under 1 hour. So those are the teams that are really performing, and they have their whole process from having some form of code to be merged, tested and deployed, and that should be done in under an hour. So to refute what CI CD is we would need to contradict the Dori board, which is the best approach and the best way that we have at the moment. What is your development workflow? And if we were face to face, I would ask and get some feedback from all of you. But let's go into a typical workflow that exists in many organizations. So feature branches. So most companies have some form of main branch or master branch from which they do feature branches. So what is a feature branch? In theory, a feature branch is a branch where you develop an entire feature for your product. So my question would be, what would be the process? By using feature branches, you are probably doing pull requests, right? So you have a master branch, you create a feature branch to develop some kind of feature, when you're ready for that to be tested, that you open a pull request that someone will review, and then eventually it will be merged on a main branch. So pull requests are usually tied with code reviews. So code reviews are used to ensure, in theory, are used to ensure that code, that your code is actually doing what it is supposed to do and adhering to some rules that are pre established. So what is the number one reason for code reviews? Usually the code reviews are done. So to ensure that code don't like tests and that it follows all the best practices. The problem with this is that prs are slow. So you do a branch, you submit a pull request, you do a code review and it eventually gets merged. So let's just go through an example scenario. So you make a change, you submit a pr to be approved. It takes some time for someone to pick up that pull request and do the review. Let's say 10 minutes, 1 hour could be a week. Let's say, for example, 10 minutes. So someone stopped working. So you will be at least 10 minutes waiting for someone to review that pr. Then it needs to be reviewed. If everything is okay, you'll get a thumbs up. If not, you'll have to go back and forth with the reviewer to have your changes up to the standard theyre supposed to be. And then you'll have to be waiting while this iteration is going. This means that CI, so if we want to follow theyre CI practices, we need to do this multiple times a day. So let's imagine a team of four, five, six, whatever number of engineers, everyone, to follow this CI CD mindset. Everyone would have to do this multiple times a day. So people will keep getting interrupted to do, for example, course reviews on prs. How often do you really want to be interrupted daily? And how many reviews can you actually do per day. And for CIT to work again, you need to do at least one review per change per day. So what we can do is to bad changes, which means no CI CD, it's also async, and there's no two way communication. So what are some alternatives to this? So an alternative is to use trunk based development. This means that you can submit directly to a master or trunk or a main branch, or you can create short lived branches and that can be merged directly, directly to a main branch. So the data from the state of DevOps report is clear. Trunk based development predicts higher throughput and better stability, and even higher job satisfaction and lower rates of burnout. And this comes from the DevOps Handbook. You could be asking yourself, yeah, but with PRS, we have code reviews. We can also do that with trunk based development. You can do, for example, pair programming, right? So the idea of pair programming is that, for example, two engineers are working on the same piece of code, and they are reviewing while one is writing and the other is reviewing and they are discussing the changes. But pair programming usually has some kind of criticism. Dismissify some of that criticism. So the first criticism is inefficiency. So it means that two devs working on the same code is wasteful resource. In practice, that's false. And we have evidence that can be found in the case for collaborative programming by John Nosek. Another criticism, it's that it is uncomfortable. So most people who try find out in reality that it's not the case, but this one is down to personal preference. The other criticism is lack of focus and intrusion, which is also false. Pairs are usually able to sustain a better focus than an individual alone, and then we can see evidence of that on a comparison of solo and pair programming in terms of flow experience, coding quality, and coding achievement. In the Journal of Education and Computing Research. The other criticism that the pair programming has is the fact now that we work a lot remotely, that we will have to, people have to be working remotely on pair programming, and the problem might be, for example, different time zones. So we can try and find a middle ground here. So I stole the fluid pull request name from my colleague Marcelo, but this idea is something that I've been doing for some years now, and it's the idea that we have some kind of a middle ground between a full pull request and a trunk based pull request. This means that you'll have policy specifications so you can specify which changes, which changes are low risk and can be automation merged, and who are the best people to review these changes. And all of those are policies that are pre established before you start developing. So you need to trust developers to merge before code reviews are done. And you need to keep track of those pull requests that should be reviewed after much. So the idea here is that you have code reviews is that you have some sort of policy which can tell you, for example, if this change needs to be reviewed by someone or can be automatically merged. For example, you can have, for example, changes to some sort of documentation automatically merged. But some changes, you can flag them as critical, for example, and someone needs to be assigned for review. And that can also be a policy that is specified and a specific person can be assigned to that review. So we've been talking a lot about CI CD, and if you've noticed, I haven't spoken so far of any tool, any pipeline, nothing. So I haven't talked about the well established build service like Jenkins or Azure DevOps or other types of tools, because CI CD is not about a tool, it's about a practice. So stealing from Simon Sinek, the golden circle so the why of CICD is for us to build better software. So how can we do that? By having faster feedback. And what can we do to achieve faster feedback is to have build servers, pipelines, et cetera. But the idea here is that just because we have build and deploy automation, it doesn't mean that we are doing CI CD. So we need tools and automation to do this at scale, of course. So speed reduced efforts, but theyre are helped by these tools, pipelines and build servers, but theyre are not required. So why do people usually stop here? Because usually some automation in and on itself is already very valuable. So you get the speed of just having stuff automated. Another reason is because people are fearful and they lack some trust on other people. So this means that we actually have to enforce some kind of rules. And of course it also needs some investment. You have to build the tools from the ground up to support all of this. But in essence, what CI CD tries to achieve is this, shorter development cycles. We want to increase security, we want compliance and development process in our whole process, and we want higher quality code. So before I leave you, I'll leave you guys with some reading material. So of course, two of the bibles in continuous integration and continuous delivery are the continuous delivery and continuous integration book. Regarding the Dora report, you have the very good accelerate book which describes the whole scientific process that is behind the generation of the Dora report. And like I said before, the term of fluid pull requests I told from my colleague Marcelo, but I'll leave you here with a link for his blog post from his company and a talk that he gave at the DevOps portal and DevOps tools portal meetup about fluid pull requests, and I highly advise for you guys to see that talk and have a better sense of what fluid pull requests could be. So in summary, so we talked about what is CI and what is CD. So CI is the idea that we merge changes from all the engineers into some sort of branch, at least daily. And CD is the process that we get those changes in front of our users and iterate quickly. The usually development workflow in most companies uses feature branches. So we have some sort of main branch, we perform some form of feature branch, we develop our entire feature. We submit a pull request which is reviewed and then eventually gets merged and deployed. The problem with this is that feature branches are usually long lived, which means that it's very hard to do deployment CI CD. So do that daily with feature branches. So what can we do? We can use, for example, trunk based development, which is the idea that we create short lived branches and continuously merge them and deploy them to production. To ensure that we have code reviews, we can use pair programming to actually continuously review the code while we develop. Or we can use some middle ground between full pull requests and pair programming by using the concept of fluid pull requests. So what's the problem with all of this? The problem with all of this is that usually people employ some kind of tool or some kind of pipeline and assume they're using CI CD. But as we see in practice, we haven't talked about any tool or any pipelines in specific, and we only talk about the philosophy build in between CI CD. So CI CD is a lot more powerful than just having build and deploy automation. And before I point you guys to some reading material that would be useful to expand on these topics. And that's all from my part. I hope you guys enjoy enjoyed this talk. I hope you enjoy the conference. Don't hesitate in contacting me through social. Thank you very much for attending my talk and have a great conference.