 So go CD. How many of you are aware of go continuous delivery the platform for it's a and Jenkins Yeah, more people. Thank God. So go CD is just like Jenkins, but a little bit more and I'm going to tell you about some of the best practices some of them will apply to Jenkins also, but Most of them are for go CD. Oh Yeah, and my friend Ali did a workshop here like two days back So, yeah, another thing I forgot is I'm a seven curve from ThoughtWorks. I hope you So, yeah use scripts so using What I mean by using scripts is basically you need you should not write all the commands in your Build tool in your CI tool right in Jenkins, right? A lot of people have seen like they write five seven eight or even more commands because when you use script, right? You can reuse the code like you can reuse those scripts. You can test them You can write tests for them and then track the changes also so if somebody breaks it you can just get a good blame and beat that guy probably and Try rake for this we we tried rake for this in our project and it has been really great for us like you just run rake tasks and And Another thing if you are using bascripts, you need to have that set minus e and set minus x set minus e will basically break the script Whenever some error happens and set minus x will print everything all the commands so config.xml so this is So you need to back it up continuously because it is everything for go CD well almost And go maintains a git repository for itself In the go server You just need to add a post-commit hook so that every time go commits So whenever you change something from UI it made makes a change into that config xml and commits it You just need to have a post-commit hook and push it somewhere. That is safe So artifacts artifacts are these things which your builds produce like when you run tests when you compile your code, right? You just need to You when you compile your code and let's say you create a jar or you create a rpm or whatever and It has been tested, right? So you need to keep it safe. They are they're very precious But they're precious only till you need them like they have been deployed to production and then they have been rolled out of production for years You don't need them So go has this option called never clean up artifacts for some pipelines, but it can be dangerous because The way go cleans up space so when go maintains the history of artifacts, right? It says it has this option like when this space is less than X start deleting till you have XGB free so Let's say you marked a lot of builds never clean up artifact and there are a few builds which are Which which don't have this thing marked you basically end up go leaving no choice But deleting all artifacts of those builds so sorry even those artifacts whose Like which were built like a second ago and they just get deleted so This is another reason why you should have a separate disk for where live go artifacts This is the location where artifacts are stored in on go server so if let's say so in where log right if if you have a bad program which is Creating a lot of logs that might also end up telling go to delete artifacts And you don't want your recent artifacts to be deleted. So it's generally like I would suggest to use a separate disk or a partition I think is templatize so go gives you a very good feature called templating So your builds right they can be template they can be made into a template and those templates can be parameterized to create pipelines so yeah when you When you see your prod deployment and staging deployment they differ by only a few parameters like a chef environment name or a few IP addresses Or it can be like where to pick the artifact from what artifact to deploy right so You can just create a template and have these things as parameters when you create the pipeline you give those parameters and you have Like you have one one build So another thing is the similar thing applies for building multiple projects So you have like five repositories all of them build it's a scala code you you just you know You need to do scala compile and scala test and scala SBT. Sorry SBT make rpm and it all does the all of them would do the same thing. So why not have a Why not have a same Template and just different repositories So basically saying no to duplication and when you when you want to change something Give me one second one minute when you want to change something you thank yourself one day Yeah, and Fan in so parallelize everything give me just one one minute. I'm really sorry So fan in is very brilliant feature that if you have a source code and you have two builds and then accept a test Then you want to package it So basically this package will wait until both of them have been finished So basically you are running multiple tests parallely on different agents. So you are getting lesser build time or jobs are also an alternative But jobs so all these jobs will wait for the next job to run So the palliation happen can happen at only one level here, but these are also Good things and when you get lesser build time you have more team happiness and more team happy They would praise you like God's So note the trigger policy this is the last thing promise So when you so re-triggers happen when like cucumber test they have put some weight and all and it fails I have seen a lot of people just re-trigger the build three times four times maybe it passes sometimes and This is very bad because some smart guy one said once a window in the building is broken and left an Unrepair the building starts to go downhill Rapidly, so if you have these unmentend things and people have this habit of re-triggering re-triggering, right? this thing grows and As I promised this was last. Thank you