 Oh, bila-bila, boleh semua orang mendengar saya di belakang? Ya. Okey, asal-asal. Hai semua, saya Serene. Saya berada di sini dengan bercakap dengan C.I. Ia dibuat C.I. C.I. Oh, ya! Ya, maaf. Panas. Saya baru-baru diperkenalkan dalam projek semasa saya dapat menghidupkan keadaan-keadaan C.I. Untuk projek itu, semasa saya memperkenalkan bahawa saya memperkenalkan bahawa C.I. dalam masa lalu, saya tidak tahu apa yang saya ada. Dan saya juga mempunyai bahan-bahan. Jadi, saya hanya memperkenalkan semuanya bersama-sama. Dan saya ingin berkongsi dengan semua orang. Jadi, hari ini akan berkongsi tentang apa yang C.I. adalah, kenapa yang terbaik, dan bagaimana untuk membunuhkan beberapa bahan-bahan yang saya memperkenalkan? Ya. Tapi seperti yang saya ada sebelum ini, sebelum saya memperkenalkan dengan C.I., saya akan memperkenalkan keadaan-keadaan yang saya memperkenalkan. Kami di Mervis Consulting. Kami adalah konsultasi software, dan kami memperkenalkan bahawa kami memperkenalkan software, dan kami juga memperkenalkan keadaan-keadaan C.I. Jadi, jika anda ada pertanyaan atau hanya ingin berbual tentang pertanyaan keadaan-keadaan C.I. C.I. C.D, hanya bercakap dengan kami, dan di sini saya akan mengambilnya. Dan juga, jika anda ada pertanyaan keadaan-keadaan C.I. atau ada pertanyaan lain, anda boleh menghubungi seseorang kita. Banyak kita berada di sana. Jadi, boleh bercakap dengan kami selepas pertanyaan. Jadi, mari kita berbual dengan itu. Adakah anda pernah mendapat pengalaman yang anda membuat kembali? Kemudian, anda dapat berbual dengan keadaan-keadaan yang berbual, keadaan-keadaan yang berbual. Jadi, anda perlu mendapat pengalaman yang berbual. Atau, jika anda membuat sesuatu yang berbual, anda tidak pasti jika segala-galanya masih berfungsi, atau jika anda berbual dengan keadaan-keadaan yang berbual, keadaan-keadaan yang berbual, dan semua masalah yang lain yang berbual, keadaan-keadaan yang berbual, terutamanya, bila banyak orang berbual, ia akan menyebabkan. Jadi, jika anda tahu, ini adalah masalah yang berbual. Kerana CIE dapat menyebabkan ini untuk anda. Jadi, setiap masalah yang berbual, kita mulakan dengan keadaan-keadaan yang anda cuba menyebabkan. Jadi, saya dapat keadaan-keadaan yang berbual dari Martin Fowler, dan saya terutamanya suka keadaan-keadaan dia, kerana ia benar-benar menyebabkan keadaan-keadaan yang berbual dan keadaan-keadaan yang berbual kepada CIE. Jadi, CIE, ia menyebabkan dan menyebabkan untuk anda. Dan ia menyebabkan banyak perkara untuk anda. Tapi kemudian, sangat menyebabkan, ia adalah sebuah hal kultur, yang bermakna, ia menyebabkan keadaan-keadaan yang berbual dan menyebabkan keadaan-keadaan yang berbual. Jadi, kita bercakap banyak tentang keadaan-keadaan yang berbual. Okey. Jadi, ini adalah sebuah keadaan CIE yang berbual. Ia akan menyebabkan. Jadi, penyelidikai yang membuat keadaan-keadaan keadaan-keadaan menjadi, sebegitu-begitu, kita bermaksud, seperti alat-alat hari malam, dan di keadaan-keadaan keadaan-keadaan keadaan keadaan-keadaan adalah keadaan-keadaan. Jadi, jika kita menyebabkan keadaan-keadaan, jika kita buka modul dan memutuskan test untuknya, kemudah, kemudian, anda akan menyebabkan keadaan-keadaan yang berbual pada keadaan-keadaan yang berbual dan anda harus berbual. So it's the developer will do that and then you're expecting that it will get to staging or production eventually. So the way it gets there is through the CI pipeline. So basically this are just some standard phases in the CI pipeline. First it compiles, then it runs your test. By the way, you have to have the tests already written. So the way we do it is we advocate test-driven development, which means you write the test for it first. So you never have to worry about whether the coverage is good enough or not. And so yes, it goes through the packaging and all that. And so at any stage if something goes wrong, the developer is immediately notified and the feedback is given at such a point that because the commit was so small, the amount of code that broke that part of CI is going to isolate the problem well enough that it's not going to be so difficult to try and fix it. And also because it's so frequent, basically the developer still has context over like the feedback loop was a lot faster. So he still has context and he can fix it easily. But yes, so if everything passes, you basically have a lot of confidence that this piece of code works and anything that reaches stadium production is going to work. Okay, so let's look at some technical aspects to CI. What CI is doing actually is that quite simply it's polling for changes, which is that if you make a change to your version control system, CI, like this arrow is always automated. So you never have to manually trigger it. And then it can build and test as well. And it's important that you can build and test from the command line because CI is basically running commands for you. And if something fails, CI stops the field commit in its tracks. So you never have to worry about a field build ever like breaking staging or production. So yes, and then finally it notifies you of the failure. And the way it notifies is there's this thing called a build radiator. And the build radiator is basically something that you can just basically just shows you the stages down. CI currently whether something's broken, something is running or not. And you can just flash this on the monitor at home. In the office. If you work at home. Or you can do like select integrations. So let's talk about some cultural requirements. So if the build radiator is saying, hey, there's a stage that failed. Culturally, everyone should take action. And the action comes in two steps. No one should be pushing to master anymore. No code should be pushed when CI is broken. And two, you have to fix it as soon as possible because no one can push anything. And if this has been fixed, like Alia I mentioned, the small frequent integrations is very important because of the benefits that it can bring. And finally, you want to keep the entire CI process running in under 10 minutes because if it runs, if it runs for too long, people are going to pick up something else or pick up a new task. And the chances of CI being left failing is a lot higher. So I just want to share as well how our team has adapted the CI workflow to work for our project. And just to give a bit of background on the project, it is a React-native project which means that the output is going to be an Android app, an iOS app, and also is served by a Rails API back end. So yes, we advocate and practice trunk-based development, which means that we work directly off master so we do not do any feature branches. And finally, you expect that these are the outputs that I just mentioned. And the CI that we use is Go CD. Let me take a little while to talk about Go CD. Go CD is an awesome, robust CI tool that I think the biggest, the most interesting thing about Go CD is that there is just a set of pipelines. So if you look at it, pipeline A and B can run in parallel. And the thing is that most importantly, pipeline C is not going to run until pipeline A and B have both stopped. And also you can pipe whatever has been run into pipeline C. So we use that and so you'll be able to see how we integrate that into our CI workflow in a bit. And so there are like a lot of plug-in support. So one plug-in plug-in that we use is we use a plug-in to upload the artifacts to an object storage. So if you want to see a certain commit, whatever, whatever was the output of a certain commit, you don't have to rerun CI or whatever. You just have to go to the artifact and get it. And also it's free and open source. The only thing that you have to pay for is the hosting charges for the server, which is costing us about $25 a month only. So the only thing that our team felt was maybe a bit lacking was the kind of a clickety-gooie that they have. If you want to add a task on a certain pipeline, it takes many-many screens and a few clicks. But there are ways around it because you can change configuration files. I just code. And there are things that you can do to use code and change that code. So, yes, back to our CI workflow. So earlier I mentioned we have one pipeline that is running our front-end app and another one that is running our back-end. And only after those two have finished that we run the end-to-end test. Oh, sorry. And also, the output, not pictured here is actually a deployment. Two more deployment pipelines that fend out into the two outputs. And those two are going to go to staging. It goes to staging because we practice continuous delivery. And in continuous delivery, deployments are automated but triggered to production by a manual trigger. So, whereas that contrasts with continuous deployment, which means that every commit that you do, as long as CI passes, it goes straight into production. So, I think it's a lot of people put CI and CD together and have you ever wondered why? And I think through this exercise, I realized that they just synergized really well together. And CD kind of extends CI and that CI automates the building and testing. CD automates the deployment and because CI always makes sure that your code is always in the working state and CD gives you the opportunity to push, deploy code at any time. Together, they bring business value because then you are able to do fast releases and you're able to get that product out to your end users which is arguably the most important feedback loop which is the hardest to get. So, they shorten that feedback loop which is awesome. So, yes. So, basically I've broken down the value of CI into two parts. The development value as well as the business value. And like earlier I mentioned most of the business value is going to be regarding the extremely fast releases you can do with the combination with CI and the development value is that users refactoring maintain context like I covered earlier. But there's this point at the bottom which provides code as documentation which is which is pretty important because like for example if the person who set up the deploy pipeline is on leave and there you need to change something at the environment variable or something like that. And you realise that hey, actually all the code is documented there already. Everything you need to run is in CI. So, everything is provided as documentation. Yes. So, yes. Let me cover some of the potential misconceptions and actually misconceptions some of them that I had as well in the past. So, the first one is something that I receive very frequently in the industry in that if anyone do you practice CI and then they go like oh yes, I use this and that too and hence I practice CI but as we have seen CI is not about the tool. CI is about the practice and if you leave a build on CI then it's broken and then you just say oh yeah, I practice CI no, you're not actually practicing CI which really is to the next point. We'll fix it later is something that you don't want to say because if a field build is on CI and also or that is too early to set up CI it's actually never too early to set up CI because CI should grow as the project gets more complicated if not, if not, you get to a point where the hurdle for setting up CI is like so huge that no one wants to set up anymore and then that is when you are scaling and you really need CI for help or that yeah, I thought of this I thought of this at one point very early on CI is a cloud thing but if you think about Go CD is something that we self-host so actually we can run it on your local machine as well so CI is not a cloud thing CI is basically just the tool that automates the thing and there is a practice or that CI is too troublesome to set up if you say this then you're just like kicking the can down the road and where it will get to become a bigger problem in the future or that or that if you realise I've been working on this feature branch for like a week and I have like 300 code changes like then you're not really practising continuous integration right okay so there's some other learnings that I had that's not directly related to CI but but I realised that CI actually once I took a step back I realised CI fits really really nicely with the rest of AirJaw software development practises like because if you think about that if I thought about it and CI CI all about automating feedback looks as fast as possible and everything in AirJaw is actually about making feedback looks very very fast as well so it fits in nicely and and also this point on DevOps there's like a lot of debate over what is what a full stack developer really is and but a lot of people can agree that one of those tags does include DevOps and as a relatively new developer myself that this was restarting up CI was really my first experience with DevOps and and I do feel like it has made me more aware of the infrastructural changes that my code is going to make and it feels I feel like it does make me grow it did make me grow as a developer and yeah so so I would highly recommend like trying out DevOps if you haven't and and yeah I'd like to end it with this comic that really tickled me the first time I saw it so yes so this is about this feature becoming a bug but then if you think about it in another way like if if it's not QA but CI that called it then then actually you should be happy about it because if there is a bug but if there is a bug then CI is finding you the bug in the fastest time possible which is awesome so yes so if if this aspect you are interested and you want to find out more you can you can go to these resources or please come talk to us thank you so much you have been an often audience thank you Serene so yeah you only know what CI stands for right?