WEBVTT 1 00:00:14.279 --> 00:00:17.760 Hello, everybody, this is just Reach's Adventure and Devil. Will 2 00:00:17.760 --> 00:00:20.800 you already laughing at me? You can't put me on 3 00:00:20.839 --> 00:00:23.480 the spot? Do the intro? Now they're laughing at me? 4 00:00:24.679 --> 00:00:27.160 All right, Well, I'm Jillian Rowe and with me this 5 00:00:27.239 --> 00:00:30.760 week is Will Button and Jonathan Hall Highouse. 6 00:00:32.039 --> 00:00:34.679 And technically I'm laughing with you, not at you, because 7 00:00:34.679 --> 00:00:35.439 you were laughing too. 8 00:00:37.719 --> 00:00:40.000 It's okay. I only felt a little bit put on 9 00:00:40.000 --> 00:00:40.359 the spot. 10 00:00:40.399 --> 00:00:42.240 I'll forgive you some day to be fair. 11 00:00:42.320 --> 00:00:44.960 I did say okay, let's go and then hit record. 12 00:00:46.479 --> 00:00:48.640 I'll stand with Billian that she was put on the spot, 13 00:00:48.719 --> 00:00:51.560 but I fully support putting Billian on the spot. So, yeah, 14 00:00:54.759 --> 00:00:56.119 what are we talking about today, guys? 15 00:00:56.280 --> 00:00:58.799 All right, we're going to talk about c i CD tools. 16 00:00:58.920 --> 00:01:01.000 What do you use, what do you hate? Why did 17 00:01:01.039 --> 00:01:03.000 you use it? Do you get a choice? Does your 18 00:01:03.079 --> 00:01:04.799 job just like dictate it for you? Or do you 19 00:01:04.840 --> 00:01:07.120 have like some kind of some kind of input into 20 00:01:07.159 --> 00:01:09.680 this decision? Why would you make your decisions? Who wants 21 00:01:09.719 --> 00:01:11.640 to hit us up first? And I think you suggested 22 00:01:11.680 --> 00:01:13.680 the topics, so she gets put you on the spot. 23 00:01:13.480 --> 00:01:17.079 Now, okay, yeah, so it's a big topic. So the 24 00:01:17.120 --> 00:01:19.599 reason I thought of it is earlier this week was 25 00:01:19.640 --> 00:01:23.439 last week on LinkedIn, one of my contacts asked the 26 00:01:23.519 --> 00:01:26.280 public which CICD tool would you like me to use? 27 00:01:26.480 --> 00:01:29.120 In a demo about how to get started with CICD, 28 00:01:29.359 --> 00:01:32.200 which led into a bigger conversation of which ones are people? 29 00:01:32.319 --> 00:01:34.640 And she did a poll which gave four options, and 30 00:01:34.920 --> 00:01:37.359 none of the four options were things I'd even used before, 31 00:01:37.560 --> 00:01:39.840 and I've used probably a dozen of them. So that 32 00:01:39.959 --> 00:01:43.680 just goes to show that there's a huge selection of 33 00:01:43.760 --> 00:01:46.519 tools to pick from. And I don't know how she 34 00:01:46.599 --> 00:01:49.480 chose her for but I think it was Jenkins and 35 00:01:49.760 --> 00:01:54.120 whatever AWS provides, and maybe Azure DevOps and I don't 36 00:01:54.120 --> 00:01:56.439 know what else. You know, it's a good conversation to have. 37 00:01:56.560 --> 00:01:58.480 I think, how do you choose one of these tools 38 00:01:58.480 --> 00:02:00.280 to use? Because there's so many and they all do 39 00:02:00.439 --> 00:02:03.879 roughly the same thing. They all automate the running of tasks, 40 00:02:04.000 --> 00:02:08.840 which can be running tests, building software, tagging releases, ordering 41 00:02:08.879 --> 00:02:11.120 pizza perhaps whatever they whatever they do, they can they 42 00:02:11.159 --> 00:02:13.879 can automate these things. So yeah, I don't know how 43 00:02:13.879 --> 00:02:16.680 we want to tackle this. I mean, if somebody asked 44 00:02:16.680 --> 00:02:19.240 me quickly, Jonathan, what CSD S will do you prefer. 45 00:02:19.319 --> 00:02:20.639 I have a quick answer to that, and that is 46 00:02:20.680 --> 00:02:23.560 get laud ci. But that's not a very useful answer 47 00:02:23.560 --> 00:02:25.960 without a lot of context, because that's not the answer 48 00:02:26.000 --> 00:02:27.879 I would get to everybody. And if ask me what 49 00:02:27.919 --> 00:02:30.319 should they do, that's a different question than what do 50 00:02:30.400 --> 00:02:32.319 I prefer? So, yeah, I don't know how we want 51 00:02:32.319 --> 00:02:33.080 to tackle this today. 52 00:02:33.439 --> 00:02:36.080 I think that I think there's like two different ways 53 00:02:36.120 --> 00:02:39.800 to answer this. You know, there's I'm starting out choosing 54 00:02:39.919 --> 00:02:44.879 a CICD tool, and we have a CICD tool in 55 00:02:45.000 --> 00:02:49.120 place and we want to replace it. And for that 56 00:02:49.240 --> 00:02:55.039 latter question, my go to response is always don't. I mean, 57 00:02:55.120 --> 00:02:57.919 they all have things that they're good at and bad at, 58 00:02:58.680 --> 00:03:01.919 and the cost of transitioning from one to the other. 59 00:03:02.560 --> 00:03:05.280 There's just not enough value in it because you might 60 00:03:05.360 --> 00:03:09.960 solve one specific problem, but you're introducing other problems that 61 00:03:10.280 --> 00:03:11.719 you don't know you have problems with. 62 00:03:11.840 --> 00:03:13.520 Yet I tend to agree it's. 63 00:03:13.439 --> 00:03:16.120 Always a trade off. Yeah, everything like that is a 64 00:03:16.159 --> 00:03:16.639 trade off. 65 00:03:17.400 --> 00:03:20.240 The best CICD is the one that you already have installed. 66 00:03:20.879 --> 00:03:24.039 Usually. Yeah, So there are times when it's appropriate to change, 67 00:03:24.039 --> 00:03:27.280 but not for that reason, like if you're changing from 68 00:03:27.319 --> 00:03:29.520 at lastly and to GitHub for example, you maybe need 69 00:03:29.560 --> 00:03:31.439 to change from Bamboo to get hub actions at the 70 00:03:31.439 --> 00:03:33.879 same time, but not because you want to change your 71 00:03:33.879 --> 00:03:37.360 CSD tool, just because you're changing everything else simultaneously, for sure, 72 00:03:37.439 --> 00:03:40.240 So I would almost I mean, there have been times 73 00:03:40.240 --> 00:03:42.800 when I migrated off of a CSP tool, but there 74 00:03:42.800 --> 00:03:44.879 were cases where it was not being used properly or 75 00:03:44.919 --> 00:03:47.919 being used very little, so that there was very little 76 00:03:47.960 --> 00:03:50.800 invested and it wasn't doing much for us. So you know, 77 00:03:51.039 --> 00:03:53.080 it was basically a proof of concept that we decided 78 00:03:53.120 --> 00:03:55.199 not to continue with, if you want to make up 79 00:03:55.240 --> 00:03:57.000 that way. So that's a different scenario than I think 80 00:03:57.039 --> 00:03:59.199 what you're talking about. If you have a CICD configured 81 00:03:59.280 --> 00:04:02.680 and already doing some thing valuable, I think really hard 82 00:04:02.719 --> 00:04:06.840 before changing, really really hard. When you when you're done 83 00:04:06.919 --> 00:04:09.000 thinking hard, go think hard again. 84 00:04:10.599 --> 00:04:13.280 I think there are some good stories behind these opinions. 85 00:04:13.360 --> 00:04:16.079 You guys have a like emotional trauma to share around 86 00:04:16.319 --> 00:04:18.959 switching up c I S peoples and then realizing it 87 00:04:19.000 --> 00:04:22.199 was it was a terrible, terrible mistake. Or clearly you 88 00:04:22.199 --> 00:04:24.319 guys have never made such a mistake like that, right. 89 00:04:24.360 --> 00:04:26.439 No, No, I thought really hard and decided not to 90 00:04:26.519 --> 00:04:27.000 do it. 91 00:04:28.680 --> 00:04:32.600 I've I think my experience forming that opinion has been 92 00:04:32.720 --> 00:04:37.519 from not from switching, but from having exposure to several 93 00:04:37.560 --> 00:04:40.160 different ones, Like I've used git Lab, I've used Jenkins, 94 00:04:40.240 --> 00:04:44.199 I've used Circle CI, Travis CI and all of them. Like, 95 00:04:44.839 --> 00:04:49.800 I can't see the value. There's a fe use cases 96 00:04:49.800 --> 00:04:52.720 for it, but I can't see on the surface the 97 00:04:52.800 --> 00:04:55.879 value in switching from one to the other because I've 98 00:04:55.920 --> 00:04:58.480 I've used a lot of them, and each has their 99 00:04:58.519 --> 00:05:03.160 own strengths and weaknesses, but enough to justify rebuilding all 100 00:05:03.240 --> 00:05:05.920 that stuff, especially if you have like a lot have 101 00:05:06.000 --> 00:05:07.800 it doing a lot. You know, if you have a 102 00:05:07.839 --> 00:05:11.439 lot of different pipelines, that's going to be some pain. 103 00:05:11.560 --> 00:05:13.600 And at the at the end, you know, what did 104 00:05:13.639 --> 00:05:16.959 you really gain? What value did the customers who are 105 00:05:17.000 --> 00:05:19.920 buying or using your product to get from you switching 106 00:05:20.079 --> 00:05:21.240 the CICD solution. 107 00:05:21.720 --> 00:05:23.519 I want to add to that. And there might be 108 00:05:23.680 --> 00:05:26.480 times when it's appropriate to change, if you're using an 109 00:05:26.480 --> 00:05:30.079 anti antiquated tool, for example, or it's just too slow 110 00:05:30.480 --> 00:05:32.439 or it doesn't integrate with things you're needing to do. 111 00:05:32.839 --> 00:05:35.680 But if you go that route, don't change everything at once, 112 00:05:36.000 --> 00:05:38.600 just implement the new things you need. I know that 113 00:05:38.639 --> 00:05:40.959 there's the engineer and every one of us hates this 114 00:05:41.079 --> 00:05:44.439 idea of maintaining two systems, but it's worth it versus 115 00:05:45.279 --> 00:05:47.439 trying to do turn to ram everything of the new 116 00:05:47.480 --> 00:05:50.199 system and breaking stuff along the way, just to admit 117 00:05:50.360 --> 00:05:52.720 you're going to maintain two systems, one for the new 118 00:05:52.759 --> 00:05:55.680 stuff that immigrates with the Raspberry pies or whatever weird 119 00:05:55.720 --> 00:05:57.759 thing you're trying to do, and the old one that 120 00:05:57.839 --> 00:05:58.879 manages the old stuff. 121 00:05:59.160 --> 00:06:02.000 Cool. Well, what about somebody who's switching to or not 122 00:06:02.040 --> 00:06:06.920 switching but starting clean slink projects CICD tool. What are 123 00:06:07.000 --> 00:06:08.920 kind of the scenarios where we would choose one or 124 00:06:08.959 --> 00:06:11.000 the other. I have one right off the bat. If 125 00:06:11.040 --> 00:06:13.720 you have data or some kind of data or software 126 00:06:13.759 --> 00:06:16.560 that have to be private. There are scenarios where you 127 00:06:16.600 --> 00:06:19.920 can use the open ones like GitHub, GitHub, circle, all 128 00:06:19.959 --> 00:06:22.279 that kind of thing. Most of them now, I think, 129 00:06:22.360 --> 00:06:25.920 do allow for at least some actions or like CICD 130 00:06:26.199 --> 00:06:28.279 minutes or I forget exactly how it's metered. I think 131 00:06:28.279 --> 00:06:30.199 on GitHub it's tide of the number of actions or 132 00:06:30.199 --> 00:06:33.720 the number of minutes. I forget how much for private repositories, 133 00:06:33.720 --> 00:06:37.279 but it's often quite limited. Unless you're on a public repository, 134 00:06:37.480 --> 00:06:39.560 so that could be a reason to change. You're like, Okay, 135 00:06:39.560 --> 00:06:41.639 we have this heavy duty workload. It has to be 136 00:06:41.680 --> 00:06:44.920 private for some reason, so either we need to take 137 00:06:44.920 --> 00:06:46.839 get hub a bunch of money, or we need to 138 00:06:47.240 --> 00:06:49.639 move it onto something in house like Jenkins or get 139 00:06:49.720 --> 00:06:52.680 lab that's managed internally. But really that's it. That's the 140 00:06:52.720 --> 00:06:55.600 only differentiation that I make because all my stuff is 141 00:06:55.600 --> 00:06:58.560 in make files anyways. So I can be on GitHub, 142 00:06:58.720 --> 00:07:01.199 I can be on Jenkins, be anywhere because it's called 143 00:07:01.279 --> 00:07:03.680 colin make, you know, like make tests or whatever. Then 144 00:07:03.759 --> 00:07:04.160 there we are. 145 00:07:04.439 --> 00:07:07.920 So my simple answer is use whatever's easiest to get 146 00:07:07.920 --> 00:07:10.759 started with. And if you're using GitHub, that probably means 147 00:07:10.759 --> 00:07:12.759 to get hub actions. Pre using git lab it probably 148 00:07:12.759 --> 00:07:15.959 means to get lab CI. If you're using Bitbucket, it 149 00:07:15.959 --> 00:07:19.160 probably means Bamboo. If you're I don't know when it 150 00:07:19.199 --> 00:07:21.439 would ever mean Jenkins. I can't think of a reason 151 00:07:21.480 --> 00:07:25.839 to start using Jenkins unless you're already using it. So 152 00:07:26.000 --> 00:07:28.560 do you? Uh, Maybe you just want to become a 153 00:07:28.879 --> 00:07:32.600 Maybe you like pain and like to learn old systems 154 00:07:32.639 --> 00:07:35.079 because it feels fun, like, you know, get a Commodore 155 00:07:35.120 --> 00:07:37.360 sixty four at the same time, why don't you. 156 00:07:37.040 --> 00:07:39.160 You can on a Commodore sixty four? 157 00:07:39.240 --> 00:07:43.879 Can you? I'm sure you can't, but it sounds like 158 00:07:43.879 --> 00:07:45.759 a good project. I think I might have to learn 159 00:07:45.800 --> 00:07:51.480 Jenkins and Commodore sixty fours now. So that's my short answer. However, 160 00:07:52.360 --> 00:07:54.560 So that's what that usually means. If somebody takes that 161 00:07:54.600 --> 00:07:56.639 at face value, that probably means using get hub actions 162 00:07:56.680 --> 00:08:00.160 because it's it's easy. Most people use get hub their 163 00:08:00.240 --> 00:08:03.120 coporate actions. However, I think get how Actions is actually 164 00:08:03.120 --> 00:08:06.240 a really bad tool. It feels like a version zero 165 00:08:06.319 --> 00:08:09.360 point six of get lad ci, you know, it feels 166 00:08:09.399 --> 00:08:11.199 like it has a lot of rough edges. Still, it's 167 00:08:11.319 --> 00:08:14.720 not really intuitive to use yet. The one killer feature 168 00:08:14.759 --> 00:08:17.800 it has over get lad Ci is is this sort 169 00:08:17.839 --> 00:08:21.120 of pre bundled ability to just PLoP in other people's code, 170 00:08:21.480 --> 00:08:23.160 what do they call it their marketplace. You can just 171 00:08:23.680 --> 00:08:26.639 you know, choose an action from some random person off 172 00:08:26.639 --> 00:08:29.079 the street and start running it. It also strikes me 173 00:08:29.079 --> 00:08:33.960 as really dangerous. It's like it's like n PM for 174 00:08:33.960 --> 00:08:37.000 for get houb actions and who wants that? Really? Right? 175 00:08:38.799 --> 00:08:41.720 I just picked up the Helm release from GitHub Actions. 176 00:08:41.799 --> 00:08:45.080 There's I don't know what the doctor doctor builds push 177 00:08:45.320 --> 00:08:47.120 like that's the that's all I'm doing. 178 00:08:47.840 --> 00:08:53.519 So if you don't care about security. 179 00:08:53.279 --> 00:08:55.919 Well see no, if you care about security, I still 180 00:08:55.919 --> 00:08:57.919 think you should be hosting it in house. That's I 181 00:08:57.919 --> 00:08:58.639 think that's well. 182 00:08:58.639 --> 00:09:01.519 There's different aspects of security though, I mean, yeah, I 183 00:09:02.039 --> 00:09:04.000 mean it depends how much you care about security, right, 184 00:09:04.000 --> 00:09:05.840 But I mean if you don't care about security and 185 00:09:05.879 --> 00:09:08.559 you want easy then maybe get have actions is fine 186 00:09:08.679 --> 00:09:10.639 if you don't have to edit them yourself. If you 187 00:09:10.679 --> 00:09:12.720 need to edit them yourself, then the learning curve goes 188 00:09:12.799 --> 00:09:15.679 up really quickly compared to just picking something from the 189 00:09:16.600 --> 00:09:21.039 at least and Yammel and and more than that. I mean, 190 00:09:21.120 --> 00:09:24.399 JavaScript isn't the hard part. It's it's the format and 191 00:09:24.639 --> 00:09:26.600 the way the different actions interact with each other and 192 00:09:26.639 --> 00:09:30.159 trying to tie puzz them together. So if you need 193 00:09:30.200 --> 00:09:33.799 something more more customized, I think get lab CI is 194 00:09:33.960 --> 00:09:36.840 far easier to use and get actions for simple things, 195 00:09:36.879 --> 00:09:38.320 either any of them will work. I mean, if you're 196 00:09:38.360 --> 00:09:41.039 just writing a cell script, you can do that anywhere now. 197 00:09:41.080 --> 00:09:42.759 But if you need something more complicated, I feel like 198 00:09:42.799 --> 00:09:45.360 get lab is easier. That part of that's probably because 199 00:09:45.360 --> 00:09:47.799 I've been using it. Longer, so I have the mental 200 00:09:47.799 --> 00:09:49.879 model better in my head. But I've heard many other 201 00:09:49.879 --> 00:09:51.440 people say the same that they feel like get lab 202 00:09:51.759 --> 00:09:54.720 CI is more mature product and get have actions that 203 00:09:54.759 --> 00:09:55.840 probably won't be true forever. 204 00:09:55.919 --> 00:09:58.000 I explicated, like you have to build for a bunch 205 00:09:58.039 --> 00:10:00.639 of different hardware, so you have like really complic matrix 206 00:10:00.679 --> 00:10:03.519 builds because I'm just running make tests like the time, 207 00:10:03.759 --> 00:10:05.600 like make tests the doctor build and that's. 208 00:10:05.919 --> 00:10:07.919 Yeah, if that's all you're doing, you're you're pretty good 209 00:10:07.960 --> 00:10:09.879 to go. If you're trying to deploy to Kubernetes at 210 00:10:09.879 --> 00:10:12.000 the same time, you know, if if you want to 211 00:10:12.000 --> 00:10:16.320 automate your deployments to Kubernetes or to Heroku or to whatever, 212 00:10:16.679 --> 00:10:19.840 then to Firebase, then you have other things that need 213 00:10:19.879 --> 00:10:22.399 to be done. You need to integrate your your authentication 214 00:10:22.519 --> 00:10:24.399 with those things. So you know, there's a certain number 215 00:10:24.440 --> 00:10:27.399 of complex steps that need to happen. If you start 216 00:10:27.440 --> 00:10:31.440 to do interstep dependencies, things get complicated very quickly. In 217 00:10:31.480 --> 00:10:34.360 other words, say you have five repositories and they each 218 00:10:34.360 --> 00:10:37.480 film an artifact, and then whatever one of those is updated, 219 00:10:37.639 --> 00:10:40.360 you rebuild a master artifact that takes you know, those 220 00:10:40.399 --> 00:10:42.639 libraries and compiles of together the single thing and then 221 00:10:42.679 --> 00:10:44.519 deploys it. So things like that they can start to 222 00:10:44.519 --> 00:10:47.240 get complicated quickly. And no doubt you can do any 223 00:10:47.240 --> 00:10:48.919 of these things with any of the tools. It's a 224 00:10:48.960 --> 00:10:52.240 question of how difficult. And this is why, going back 225 00:10:52.279 --> 00:10:55.279 to Will's earning point, if you already have this working, 226 00:10:55.480 --> 00:10:57.000 for God's sake, don't redo it. 227 00:10:58.320 --> 00:11:03.159 Yeah, I think about these like really specialized CICD tools 228 00:11:03.360 --> 00:11:05.080 that I'm starting to see pop up. So we were 229 00:11:05.120 --> 00:11:07.399 talking a bit before the show, as we do before 230 00:11:07.399 --> 00:11:10.639 we press record, about this tool that I'm using called Spacelift, 231 00:11:10.720 --> 00:11:12.759 which is I think it's kind of supposed to be 232 00:11:12.799 --> 00:11:16.200 like terraform Cloud, except hopefully hopefully less expensive for me 233 00:11:16.279 --> 00:11:18.519 and my wallet. But no, no, I'm kidding, Like it 234 00:11:18.519 --> 00:11:20.320 looks good, but it has these sort of like managed 235 00:11:20.399 --> 00:11:23.679 terraform environments, and it's very specifically for people doing terraforms 236 00:11:23.720 --> 00:11:27.240 with care about security and policies and maybe building different 237 00:11:27.320 --> 00:11:31.159 terraform modules and also protecting your like your stacks as well, 238 00:11:31.200 --> 00:11:34.840 so you can insert these policies to you know, say 239 00:11:35.440 --> 00:11:37.399 don't kill it if this happens, or kill it if 240 00:11:37.440 --> 00:11:39.120 this happens. Like these kind of things that are very 241 00:11:39.120 --> 00:11:42.519 specific to deploying infrastructure, and I think now GitHub has 242 00:11:42.519 --> 00:11:45.720 one maybe for JavaScript or for CI like you know, 243 00:11:45.799 --> 00:11:47.519 like I don't, I don't know, but I do feel 244 00:11:47.519 --> 00:11:49.000 like it's kind of a trend to see these more 245 00:11:49.120 --> 00:11:53.720 very specialized CICD services pop up for particular frameworks and 246 00:11:53.759 --> 00:11:56.039 code tools and things. Are you guys seeing that too? 247 00:11:56.519 --> 00:11:59.159 I haven't, but I'm the work I'm I've been on 248 00:12:00.039 --> 00:12:03.840 stainly has been pretty generic work, you know, not anything 249 00:12:03.840 --> 00:12:07.879 specific that sounds like it's pretty pretty siloed to address 250 00:12:07.879 --> 00:12:10.600 a specific use case. And I can imagine if you're 251 00:12:10.639 --> 00:12:13.440 in that use case, you're feeling that pain. But if 252 00:12:13.440 --> 00:12:16.200 you're not in that use case, then you probably don't 253 00:12:16.200 --> 00:12:17.120 know that it exists. 254 00:12:17.639 --> 00:12:21.399 So I have not used any specific tools like that, 255 00:12:21.559 --> 00:12:24.840 but I've definitely used things that are intended to plug 256 00:12:24.919 --> 00:12:29.559 into an existing CICD tool or pipeline for specific needs, 257 00:12:30.000 --> 00:12:33.360 you know, simple things. Sonarchy was an example, or depending 258 00:12:33.360 --> 00:12:36.279 on the Textec you're using, you might have specific linters 259 00:12:36.320 --> 00:12:38.960 for your for your language or your tool set. You know. 260 00:12:39.000 --> 00:12:40.159 We had a guest on if you want to go 261 00:12:40.399 --> 00:12:43.559 talking about doing this sort of analysis for Kubernet's manifests 262 00:12:43.600 --> 00:12:45.320 and you know, so that would be a tool that 263 00:12:45.399 --> 00:12:48.440 you could plug into any CICD pipeline, whether it's get 264 00:12:48.480 --> 00:12:50.840 hub or get lab or genkins or whatever. So I've 265 00:12:50.919 --> 00:12:52.480 used a lot of those, and you know, so you 266 00:12:52.519 --> 00:12:55.120 sort of build up your pipeline with all these different tools. 267 00:12:55.600 --> 00:12:59.600 Some of those sometimes are are more sasas than like 268 00:12:59.799 --> 00:13:02.600 a tool one that I've used is called coke co 269 00:13:03.039 --> 00:13:05.360 or other co covered tools. Cover alls is not the 270 00:13:05.399 --> 00:13:08.480 one where they just do like reporting of your test 271 00:13:08.480 --> 00:13:12.639 coverage stats, but they usually have a thin hook into 272 00:13:12.639 --> 00:13:16.559 your CICD tool that reports the stats with a mainline 273 00:13:16.600 --> 00:13:19.120 tool or over a STAPI or something like that, and 274 00:13:19.159 --> 00:13:21.559 then you log into their web interface to see all 275 00:13:21.559 --> 00:13:23.559 the fancy reporting you do. So that's kind of a 276 00:13:23.639 --> 00:13:26.440 hybrid solution there. You know, it's a stable one tool, 277 00:13:26.519 --> 00:13:28.960 but it hasn't hooked into your existing thing. I think 278 00:13:29.000 --> 00:13:31.559 what you're talking about is more of a holistic thing 279 00:13:31.639 --> 00:13:34.080 for a specific use case. So I'm not mistaken, And 280 00:13:34.360 --> 00:13:37.360 it sounds like it more maybe applies more to like 281 00:13:37.720 --> 00:13:40.679 a low code or no code type of product, or 282 00:13:40.720 --> 00:13:44.200 maybe not product, but like problem solving. I don't know how, 283 00:13:44.480 --> 00:13:46.200 I don't know if I understand exactly what you're saying. 284 00:13:47.200 --> 00:13:49.679 What I'm seeing is a lot of enterprise companies that 285 00:13:50.159 --> 00:13:52.960 are having trouble hiring people or maybe just don't want 286 00:13:53.000 --> 00:13:56.120 to hire, you know, like as many people as they need, 287 00:13:56.120 --> 00:13:58.480 and are starting to outsource to these different agencies and 288 00:13:58.519 --> 00:14:01.600 different services. So instead of hiring their own Terrorform expert, 289 00:14:01.639 --> 00:14:04.559 they're going a Terraform cloud and signing up for whatever 290 00:14:04.600 --> 00:14:07.200 the highest SLA plan is and getting some kind of 291 00:14:07.240 --> 00:14:09.320 support through that. So I'm not even sure that it's 292 00:14:09.320 --> 00:14:11.360 so much the software as it is about to support, 293 00:14:11.600 --> 00:14:14.120 to be honest, you know, like when I'm actually looking 294 00:14:14.159 --> 00:14:16.000 at it, I'm like, ah, which way is that? So 295 00:14:16.679 --> 00:14:18.399 I don't know. I don't know because I'm still pretty 296 00:14:18.399 --> 00:14:20.080 new to these kind of things myself. I am checking 297 00:14:20.080 --> 00:14:22.639 out Spacelift for some of my like for some of 298 00:14:22.679 --> 00:14:24.559 my stacks and things, and it does look like it 299 00:14:24.600 --> 00:14:27.399 will be good, especially after I had a very expensive 300 00:14:27.399 --> 00:14:30.919 AWS bill a couple months ago last month that wasn't 301 00:14:30.919 --> 00:14:32.799 even a couple months ago. I've just got like, you know, 302 00:14:33.080 --> 00:14:34.960 I'm still upset about that. So that's kind of what 303 00:14:35.000 --> 00:14:37.080 made me start. That's what made start looking at this 304 00:14:37.159 --> 00:14:39.879 kind of thing, was that I had this really expensive AWS bill, 305 00:14:39.960 --> 00:14:42.200 and I was like, oh, maybe I should make sure 306 00:14:42.240 --> 00:14:44.759 my stacks are actually getting destroyed when I think they 307 00:14:44.799 --> 00:14:47.440 should be getting destroyed. And since I just had a 308 00:14:47.480 --> 00:14:50.120 two thousand dollars AWS bill, maybe it would be worth 309 00:14:50.159 --> 00:14:51.919 me throughout a couple hundred bucks a months at it, 310 00:14:51.919 --> 00:14:54.440 because that's I mean two thousand that's ten months of 311 00:14:54.679 --> 00:14:57.679 spacelift while I'm looking at it. So I don't know, 312 00:14:58.080 --> 00:15:01.039 I'm still figuring these things out too, Okay, anybody thought 313 00:15:01.039 --> 00:15:04.840 I had any answers? Answer is no, I don't. I'll 314 00:15:04.919 --> 00:15:06.440 just figuring along. 315 00:15:06.759 --> 00:15:09.240 I'm curious to hear what's CICD tools each of us 316 00:15:09.320 --> 00:15:12.639 have used, and maybe just brief impressions, you know, if 317 00:15:12.639 --> 00:15:14.559 you liked incoins or not likedcons and why you know, 318 00:15:14.720 --> 00:15:15.480 in a sentence or. 319 00:15:15.440 --> 00:15:19.320 Two, I love and hate Jenkins. You know, Yeah, I've 320 00:15:19.399 --> 00:15:21.840 used it quite a bit. And the thing I love 321 00:15:21.879 --> 00:15:24.600 about it is you can do absolutely anything with it. 322 00:15:24.840 --> 00:15:27.440 And the thing I hate about it is you can 323 00:15:27.480 --> 00:15:31.120 do just absolutely anything with it. So I like, yah, yeah, yeah, 324 00:15:31.240 --> 00:15:33.519 I had a scenario. I know this is longer than 325 00:15:33.519 --> 00:15:36.879 my two sentences, but I'm gonna do it anyway. That 326 00:15:37.679 --> 00:15:40.240 a few years back, I was working with a company, 327 00:15:40.399 --> 00:15:43.440 and I think this ties into your statement about which 328 00:15:43.480 --> 00:15:45.600 c ICD you know do the simple one. We had 329 00:15:45.600 --> 00:15:50.759 one We were moving this application from Heroku to AWS 330 00:15:51.320 --> 00:15:55.320 and Heroku has their own pipeline tool that works really, 331 00:15:55.399 --> 00:15:59.000 really slick, and I wanted to in moving to ABS, 332 00:15:59.039 --> 00:16:01.759 I wanted to make sure that we didn't lose any features, 333 00:16:02.240 --> 00:16:06.000 and so we went with Jenkins. And the scenario was, 334 00:16:06.480 --> 00:16:08.879 you know, you would write your code, you would push 335 00:16:08.919 --> 00:16:12.120 it up, you would run the tests, all pretty straightforward stuff. 336 00:16:12.120 --> 00:16:14.559 But then when you opened up a poor request, we 337 00:16:14.600 --> 00:16:18.720 would create a poll request environment, so we would spin 338 00:16:18.799 --> 00:16:24.559 up the Docker containers, provision the databases, create the load balancers, 339 00:16:24.639 --> 00:16:27.960 create the route fifty three DNS entries, all of that 340 00:16:28.000 --> 00:16:30.440 stuff so that anyone who was reviewing your code had 341 00:16:30.440 --> 00:16:35.679 a working environment to see what the actual end product 342 00:16:35.759 --> 00:16:39.000 looked like. And then when that poor request was either 343 00:16:39.120 --> 00:16:42.039 merged or closed, it tore down that environment, and that 344 00:16:42.159 --> 00:16:45.200 kicked off the build process to build the Docker images, 345 00:16:45.240 --> 00:16:50.679 pushed those up into the ABS Docker registry, deployed to 346 00:16:50.759 --> 00:16:54.360 the staging environment, and all of that kind of stuff. 347 00:16:54.399 --> 00:16:56.480 So it was pretty There was a lot of moving 348 00:16:56.559 --> 00:17:00.679 pieces and nothing really had the ability to do that 349 00:17:01.320 --> 00:17:05.559 without writing your own Python accessing the photo three library. 350 00:17:05.880 --> 00:17:08.880 And so that's where Jenkins came in handy, because you 351 00:17:08.880 --> 00:17:12.799 could just give it this application or this code that 352 00:17:13.039 --> 00:17:15.880 accessed Boto three and it would do it, and then 353 00:17:15.920 --> 00:17:18.960 you could secure that with im permission, so that Jenkins 354 00:17:19.000 --> 00:17:21.839 only had access to what it needed to, which was 355 00:17:21.880 --> 00:17:24.160 still a lot, because it had access to S three 356 00:17:24.319 --> 00:17:28.160 and rds and firegate and Route fifty three and the 357 00:17:28.200 --> 00:17:29.799 load balancers and all that kind of stuff. 358 00:17:30.000 --> 00:17:32.200 That is cool, though Human in the loop, well, I 359 00:17:32.279 --> 00:17:34.480 like it, yeah, And. 360 00:17:34.440 --> 00:17:36.160 The part that I hate about that is when you 361 00:17:36.200 --> 00:17:39.039 get to that level of Jenkins, you know, you write 362 00:17:39.039 --> 00:17:42.240 your Boto three stuff, and then you have a Jenkins 363 00:17:42.319 --> 00:17:46.079 DSL that knows how to call and access that, and 364 00:17:46.200 --> 00:17:49.039 when there's an error in it, you get a Java 365 00:17:49.119 --> 00:17:53.079 stack stack trace, so a Java stack trace that refers 366 00:17:53.119 --> 00:17:56.960 to a DSL that refers to a Python Vota three library, 367 00:17:57.400 --> 00:18:00.440 so that any error messages you got were just adsbsolutely 368 00:18:00.519 --> 00:18:02.200 worthless fascinating. 369 00:18:02.519 --> 00:18:04.559 Have you used any others or is that really the 370 00:18:04.599 --> 00:18:05.880 main one you used? 371 00:18:05.920 --> 00:18:07.880 Will That's the only one I've really gone deep with. 372 00:18:07.920 --> 00:18:11.200 I've used a Circle, CI and Travis and get lab, 373 00:18:11.599 --> 00:18:15.960 but all for just really a high level basic CiCe stuff, 374 00:18:16.000 --> 00:18:17.400 nothing that extensive. 375 00:18:18.960 --> 00:18:21.480 My first introduction to CSD was a Travis. I was 376 00:18:21.480 --> 00:18:23.680 working at a company several years ago where we actually 377 00:18:23.680 --> 00:18:27.359 hosted our own on prem Travis Travis Enterprise. That was 378 00:18:27.400 --> 00:18:29.319 the first time I used CI, and I really, I 379 00:18:29.359 --> 00:18:33.000 really liked it. I later came to prefer the get 380 00:18:33.079 --> 00:18:36.359 lab model, which maybe Travis has changed since then, but 381 00:18:36.759 --> 00:18:39.559 get lab has the concept of pipelines and Travis didn't 382 00:18:39.559 --> 00:18:42.160 really have that concept. So I prefer the pipeline approach. 383 00:18:42.559 --> 00:18:44.359 In fact, if somebody was an asked me, how would 384 00:18:44.359 --> 00:18:46.279 you choose a good CI tool, I would say that 385 00:18:46.319 --> 00:18:48.079 could be the first thing. Look, so does it have 386 00:18:48.160 --> 00:18:50.359 pipeline support because it doesn't have to. I don't know 387 00:18:50.359 --> 00:18:52.480 if Jenkins does. I don't know if he uses that model. 388 00:18:52.519 --> 00:18:55.839 Okay it does. Yeah, well that that model is available. 389 00:18:56.359 --> 00:18:59.599 Like you just log into Jenkins and point and click 390 00:18:59.599 --> 00:19:02.039 your way tout success. You don't get the pipeline model, 391 00:19:02.079 --> 00:19:04.880 but there is if you write your own pipelines, and 392 00:19:04.880 --> 00:19:08.000 that's what we did there. There was a we created 393 00:19:08.000 --> 00:19:11.319 a Jenkins library that executed the pipeline and then each 394 00:19:12.079 --> 00:19:14.720 development team had a YAML file in their repo where 395 00:19:14.720 --> 00:19:18.400 they could specify how many running containers they wanted, the 396 00:19:18.440 --> 00:19:22.559 memory and CPU allocated to each doctor container, and for 397 00:19:22.680 --> 00:19:25.880 auto scaling, could specify your metrics of whether you scaled 398 00:19:25.960 --> 00:19:29.200 on memory, CPU, or latency and what that value was. 399 00:19:30.680 --> 00:19:33.079 I've also used Circle a little bit on one of 400 00:19:33.119 --> 00:19:34.960 the open first projects I help with, so I don't 401 00:19:35.000 --> 00:19:37.920