mergeconflict291
===

[00:00:00] James: Welcome 

back everyone to mergeconflict. I never opened a podcast his way, but I totally am because for once I actually do not know what we're talking about. Cause my amazing co-host Frank Kruger who's with us every single week has the most amazing topic ever. What the heck are we talking 

[00:00:25] Frank: about? Well, I guess I kind of owe you because the last few episodes, except the lightning around.

So I'm, I'm usually in the blank. I'm like, James, what are we talking about? It's like, don't worry, man. You got this. So, uh, don't worry, James, you got this. We are doing kind of a followup episode from many moons ago. Feels like once or twice or maybe six times a year. We'd like to talk about. Continuous integration and continuous delivery.

Now don't run away everyone. I'm going to try to make us interesting. Cause I'm really excited. I have hit a milestone in my app development career when I commit code to a repo and do the pushy pushy thing, upload it to a server. Something gets uploaded to apple and delivered onto my device automatically.

I know, I know you're all rolling your eyes. You've been doing this for years, but I've finally done it and I've learned a lot of lessons and James, I just want to do a whole episode talking about my adventures in OCD. 

[00:01:25] James: Uh, are you saying that for the last 15 years of your professional mobile development life, you've been right.

Click archiving and publishing from your. Yes. 

[00:01:34] Frank: Yes. Using multiple apps over the years. Uh, it's been multiple ways. What we used to have the like uploading app used to do that. I used to do the Xamarin thing where they would sign it for you in visual studio, and then they would upload it. Did that for a little while.

Finally, I settled on archiving going into X code resigning in X code and uploading from there. Yes. All manually. Uh, That might explain why I don't have too many releases of my apps or why it's a little bit painful for me to get releases of my apps out. So that was at, um, we've talked about CD before and all kidding aside, the manual process, isn't actually that much work.

What I've concluded was it was enough work that I just wasn't doing it. And I wasn't getting releases out. It was something that's really been frustrating me, honestly, about my own work and all that kind of stuff is I just want to get more bird leases out there and you know, how you do that. James, you followed James as advice and you get that continuous delivery working.

[00:02:38] James: I do like to. I think that I encourage you a little bit here, because I was talking about my holiday hack, my, my, my skiing app that I built. And you were asking me about new. We were talking about testing and I said, you know, every time I build the main branch of the application, it builds it. And app center currently today, and then it automatically ships it to test flight.

And I said, you know, I just like to. Push some code walk away and you know, 30 minutes later I have a production release ready build that could go live at any time. Because to me that's always been my mantra, which is main line is shipping code. Like you at any time should be able to ship maybe. You know, the main branch of your get repo, uh, because when I went to Canon, that was, that was the whole idea.

We had all these feature branches and there's, I mean, was this pristine quality gated release. And, uh, at any time you might need to rip off. A emergency bug fix and ship it out, but you don't have a bunch of other junk in it. So working off a feature branches off a bug fix branches and, uh, doing pull requests that would validate your bills would give you a way to test those before putting them there where they're.

So I, in the last two years, I've gone through this process. So again, you know, it's 20, 22 and. Someone may say, wow, James and Frank, do you really need to explain why continuous integration and delivery are important? Yes, we do, because it's always evolving. And let me tell you, Frank, I have tons of people all the time that are emailing me about what you had been doing.

They run into issues, trying to archive, trying to sign, uploading it and. It's a, it's a multi-step process. And so is putting it in continuous integration and delivery, uh, to, you got to put it up there, got to do this. But at the same time, people are still right-clicking in publishing. And I don't think there's anything wrong with that, by the way, you know, I don't want to shame right-click publishing because I am the worst right-click website publisher in the entire world.

That is how I do stuff. Um, half of my Azure functions are deployed that way, but half of them are NCI CD. I'm, I'm happy to say that, but, um, but you know, when I need to get something out quick, then as a, like a test website that I'm going to delete five minutes later. Yeah. I'm going to right. Click, publish and go.

Where. An app that I wanted to put in an app store goes through processes. You know, you have to figure out how to upload it, how to sign in, how to do this thing. Not to mention apple just yesterday, decided to change the entire app store process for submitting new apps, which you'll soon find out Frank, because now you have a beautiful continuous delivery pipeline that will hopefully allow you to test those releases before.

And also get them into the app store for production much, much faster. And that sounds delightful. And I'm rambling here because I'm very proud of you in my inspiration of going all in to. Did you use test flight, I assume for all of your testing? 

[00:05:56] Frank: Yeah. Yeah. Yeah. I mean, I would like to do some Android later on, but yeah, we're going to be talking about test flight this episode, that's where I've had the most experience.

And, uh, so let's say I've been doing the CGI part of the CIC D thing for a while. Now. I did get that little bit of religion. That's great. Where, uh, whenever you publish, you do a build and you run some tests. That made a hundred percent sense to me where I was always falling down was that very last leg of actually getting it uploaded and approved and all that by apple.

And basically, cause those processes always felt a complicated, but B very fragile. And I didn't like the amount of maintenance that I would have to do on them. So let's say like, I just wanted to use app center. Unfortunately, app centers set up for, uh, 90% of all apps out there, but somehow my apps all have weird build steps and weird things going on.

And. Always just kind of nuts getting a build system, even working off of my machine for some of those apps, honestly, you've worked with some of the nasty ones. So I did this work for all my apps. I did it for I circuit. I did for continuous. I did it for Coca. I feel like I'm forgetting someone out there, but, um, all, all the, all the big apps and even one of my new dotnet six apps.

And I decided this time to use get hub actions, mostly because I had gained a ton of experience with them doing CGI stuff there. And I was pretty comfortable writing those ridiculous emo files. So how about that? Have you done, have you done continuous delivery and get hub actions? Yeah. 

[00:07:38] James: No, you know, I think that listening to your story of the complexity and different dependencies that your applications are going through, I just tend not to build apps that complicated.

And there's that. Now that being said, uh, you know, app center, like I don't believe that it supports Mac applications built with.net. So I would need to go down this route for something such as my stream. I'm not going to lie, Frank. I do right. Click archive and share. So I can learn a lot here in this process, you together there, because you know, when you do, if you just UCI, which is you continuous integration of just even doing a, a build to me, see, I was like, does the thing build?

And then there's the delivery, which is like, I have a package I needed to deliver it somewhere, the CII park. And you could just be doing a simulator bill and it's like not a big deal, you know? And just did I break the bill that. Actually work or not to have something I can deliver, I'm not actually delivering it.

Um, but when you want to go deliver stuff, you need to sign that thing, right? You need to install provisioning profiles. You need to have your certs that expire. And I never quite understood. How all of those things played well in get hub and get up actions. I now understand a little bit more because I worked on the dinette podcast application, but we mostly did all the CIN CD for the microservices and the website and not for the mobile app yet.

Cause it's not shipping yet. So I'm assuming we'll do that at some point in the future, but I am very curious how this flow in GitHub actions works because. All my code is also in GitHub and I have been fascinated by attempting to even switch over some of my new get libraries that are using Azure dev ops and pipelines, which I love to put those into.

The GitHub actions for open-source projects, but then at my head keys and I got things, I don't know where to put these things, like, how does it, how do you handle like gates? Like, can you like say, okay, now I want you to send this thing here and now I want you to send this thing here. So a whole 

[00:09:51] Frank: different thing, w w we'll get to that part know, but let's do signing just cause obviously when I said fragile before this is.

By the fragile part, the signing part is the most fragile part. So let's review the signing iOS apps. What do you need? James? You need yourself assigning certificate and you need yourself, uh, provisioning profiles that are associate your app with that signing certificate. And in the case of delivering.

Those need to be distribution profiles, not, um, development months though, for the CIA, I kind of start wanting to do some developer builds, but right now I was focused on, I want to get these things into test flight. And for that you need distribution build. So distribution certificates, distribution provisioning profiles.

Now the last time. Did this was on bit rise and the way it worked was you uploaded some signing certificates and you uploaded some provisioning profiles. I hate to say things have improved a little bit, but not too much. I mean, 

[00:11:05] James: that's what I do in app center as well. Take my profiles and I shoved them in there.

And then I enter a password. 

[00:11:12] Frank: Things are a little bit better than that now. So there are, uh, I should probably get some links going here. Um, but there are some get hub actions out there specifically. I think they're called like apple actions or something. They're pretty easy to find, just search for app, uh, app store, connect actions, get hub, you know, that kind of thing.

And there's some pretty big ones out there. Um, Technology has advanced James, you know what we can do now. So that's, let's start with certificate certificate. You still put as a hub secret. So you export your private certificate from your key chain. It's all very scary and hotshot and you, uh, put a base 64 version of.

Right on to get hub with a password is a secret. So every certificate has two secrets, the base 64 version of itself, or whatever, asking coding, you can find it and, uh, the password. So two secrets for every certificate. And the modern world apple has, what's called the apple cer uh, signing certificate.

It's one that works on both iOS and Mac. But back in the day, we had separate ones for iOS and Mac, and here's where things, life is really fun, James. So if you're doing an old Xamarin, build a Mac build. It cannot accept an apple certificate, but iOS builds can, if you're doing a dotnet six Maxfield, it can accept the apple certificate.

So you happy life is fun. So you may need up to one or two certificates, uh, depending on, uh, what versions of everything you're doing, whether you have a Mac version or not, but. Hmm. So that's not too bad, right? That's kind of, I wish we could get rid of that step, but where life has finally improved is it can automatically download the provisioning profiles now.

[00:13:06] James: Oh, oh, that's cool. So you don't have to do, do you like log into your apple account then somehow, or give it a token? 

[00:13:13] Frank: Right token. So all of this stuff, it's going to work off of app center now and in the same way that, uh, my app works apps that, um, you can get access tokens to app center. I keep calling it app center, app store connect app store connect.

Um, you can get tokens to access that you log in, you go to users and then there's a key. Uh, tab and you can generate a key and there's actually three bits of information that you need from there. Um, there's an issue or ID. There's a key ID, and then there's a private key associated to all that you're gonna need all three.

So each one of those becomes a get hub C. So this sounds terrible and it is a little bit terrible. So I streamlined some of it, but so I had to do this per app, which is per repo. I haven't figured out how to do like shared secrets on get hub. There's probably a way to do that, but I haven't figured it out.

Um, I should probably look into that, cause it's already getting a little bit tedious, but basically you're just adding secrets and secrets and secrets to this thing. So the good news though, is, uh, once you get those, that connection to app store connect established, it can download all the provisioning profiles for you.

You tell it what kind you want, iOS distribution and your bundle ID, and it goes and gets them and installs them on that machine. It's wonderful. 

[00:14:42] James: That's a nice, because you know, I, the, so the, so let's, let's break this also down a little bit because the, the certificate is the one block in the chain in which you need to.

Have you have to do stuff on your Mac, right. And people always ask us all the time, how can I just not buy a Mac? And it's like, you can get really far. I mean, you could do a Mac and a cloud. Do the certificate export the every year. I guess that would be one way to do it. Um, and just hope that you don't mess up your certificates and have to do it again.

That doesn't seem as like the best process, but you, you, you have to get a certificate. That is signed and exported from apple. It's a whole rhythm, a roll process there. And that does not seem to be solved in this case because you know, something like X, X code cloud build, or whatever, their X code server you're signed into your account.

So it can figure out how to do that stuff. Automagically so here, since we're not on a Mac, then it's there. We're just in GitHub and we need to tell, get to go do this up, but it's sounds like the, the action that you found streamlines, the part, which is what like visual studio does. For example, like you log into your apple account, it grabs all the certs and does all this stuff and knows how to, to sign your application based on the stuff that you have on your machine.

The certificates on your machine, the profiles on the internet, the profiles you can download anywhere, basically. 

[00:16:18] Frank: Yup, yup. Yup. Um, and it's important because I look at it all from like a maintenance perspective. When I say fragile just means I don't want to do maintenance on this thing. I just want it to work all the time.

And so what we're down to is that certificate will expire once. And so once a year, I'm going to have to go through all my get hub secrets, but just the certificate secrets, renew my certificates, and then enter in those new certificates. I won't have to repeat that for the provisioning profiles. I will have to go to apple and renew those provisioning profiles.

Yes. But I don't have to like download on. Put them into a secret or anything. So it sounds like such a small thing, but it's, you know, after years of doing this, I really love that it can actually just download those profiles for you. Especially if like I circuit has two profiles, one for the thumbnails extension, one for the app, and then a third one for, um, uh, I circuit Mac.

So that's three profiles. That's three more secrets. I don't have to update every year on there. So that's nice. 

[00:17:21] James: Yeah. That shared. You know, that shared, um, token is, will definitely be super important because that is something that, um, as your dev ops has, for example, is that's how I do nougat is I have my new get token, which expires, you know, every so often, but you can basically say, Hey, this is, this can be accessed from all of my pipelines.

So what get hub needs. We'll be more advantageous, right. As if it's like, Hey, you can share these across multiple things. Maybe they have that. I don't know. 

[00:17:59] Frank: They probably do. And I just haven't found them, you know? So I just have to look, or there's probably a fancy way where he can get, um, Uh, way I've done it before is you get a get hub access token itself that lets you hit the get hub API, and then you can ask the API for secrets and things like that.

I've done it that way, but that's uh, you know, uh, a lot of that's I was doing working really hard not to create Rube Goldberg devices. I didn't want my build steps to be 8,000 steps of hacking away at, you know, project files and things like that. I tried to make my build as clean as possible. And for the most part, it really is.

So my builds are mostly download the source source code, um, uh, download.net, a very specific version of.net. Do a restore. Um, do a build of the main app, do run the tests of the app and then do a build of like a device build of the app, which is a much more expensive thing. And we'll get into like costs and all that stuff.

But for the most part, I'm not doing too much hacking. Now I do have a few little hacky parts, so hack number one, but you know, you have to do. Versions, you have to update the versions and put like build numbers in there and things like that. So what I kind of settled on here was what I thought was the most comfortable for me.

Everyone should do. What's comfortable for you, but I ended up putting a little version.sh file in the root of every app and that way, um, which it's a little shell script that takes as one argument that builds up. 'cause that's the only thing that is actually dynamic and any of that, I can control the version number otherwise, and it just does the right thing of puts the build number in all the right places and things like that.

And I did it as a little shell script, just so I can develop it independently of working on the build steps and everything just keeps things clean. 

[00:19:58] James: Well, you know, funnily enough, I have a bunch of Azure dev ops. Steps that do all the version bumping and can change your identifier and your title and all that stuff.

And in my GitHub, repo is a shell script. I have a TypeScript, a JavaScript, a PowerShell, and a bash script all in there. So people could take them and run them later and do all that stuff. So funnily enough, I should probably figure out how to make it get hub action. That executes, this thing makes it all work and call, but it's very minimal code, uh, in general.

But I, now I'm very fascinated in figuring this out because I'm thinking of the steps that I do inside of apps or what apps center does for me, which is what you just said, like figures out my certificates. And there was also a bumper version number. Or bumped, you know, version or whatever, you know, it doesn't do the info P list or whatnot, but it does do that incremental.

Yeah. That one that mine does too. Um, as one thing I always wish that it kind of did and, uh, upended a version number at the end or whatever. Um, but yes, that is the thing 

[00:21:06] Frank: it's hard working on this and not getting sidetracked by writing. And Uber action, you know, that takes an a million parameters and does all this for you because then you're into a weird maintenance thing, but it was always on the back of my mind, but where I settled was few steps, um, not complicated steps.

And if they were complicated steps, then it had to be a little shell script that I could test independent of the build pipeline and all that kind of stuff. That was. Yeah cause otherwise, oh boy, did I rack up some build, build minutes? 

[00:21:39] James: I do want all that stuff. I do want to talk about that stuff too, but before we do let's thank our amazing sponsor this week.

Sync fusion back for 2022. Thanks fusion for sponsoring this week's pod and in many pods in the future, listen, sync fusion has been with us for a long time. They've been with me for a long time because they build absolutely astonishing. Controls frameworks, reporting platforms, enterprise solutions with analytics and reporting dashboards.

They basically help you make your application. Even better by giving you hundreds, if not thousands of beautiful controls in widgets and things for your applications, no matter what you're developing, whether you're building a web app with blazer, asp.net core angular react view J query or mobile apps with Donna Maui.

Now in preview Xamarin, UWP, JavaScript, flutter, or desktop with just about any technology that you can build desktop applications for, they have awesome things for you. Really gonna get started with Donna Mallee. For example, they have some brand new, beautiful charts, engages affects list, view, sliders, badge view, schedulers, tab views, and all sorts of file format frameworks, which means like, do you need to work with Excel or PDF or word or PowerPoint?

I do. I just talked about it. Boom. You can drop in sync, fusion, and you are. To go, go to sync, fusion.com/merge conflict to learn more and thanks to sync fusion for sponsoring this week's 

[00:23:07] Frank: pod. Thank you. Think fusion. 

[00:23:11] James: Yes. So how do build, let's say you're building now. Here's the thing about CICT that I always find interesting is you.

Often when, when you're doing something in app center, it's kind of nice. Cause it's like, here's the repo, like build the thing. Like you can't really customize stuff. But when I start getting in dev ops or in GitHub actions and these animals, you're tweaking, you're tuning, you're running a ton of builds nonstop just to get it.

Perfect. And then it's perfect. Then you're a good for a bit, you know, for a while fully. How does do you just get unlimited minutes? Like 

[00:23:47] Frank: this work? Right. Okay. So we have to actually get back to code signing, but this is an important detour because, oh, I I've gone down quite a journey, learning all of this.

Oh, you pay James. They make you pay. So it all depends on your account. I have a pro account. It's like $4 a month or something. It's great. It's well worth the price. And with that come something like. That was the end free minutes of get hub actions for private repos. So I never really noticed any of this stuff because I did a lot of CIC CD with my public repos.

So my open source projects. And so I never really, you know, got into heavy builds otherwise, but doing these device builds, especially something like I circuit where I build for all three architecture. Um, seven arm, seven SNR, 64, and then Mack on top of that max 64 on top of that, it takes a while, like 30 minutes.

And, uh, you kind of have to do that on a Mac. So when you run to get hub action, you can tell what kind of machine to run on. And max are priced at 10 X. What. Uh, windows or analytics machine are priced at so ouch out. So if you're all doing like windows builds or Linux builds, you're fine. You're fine. But when it comes to Mac builds, it gets expensive really fast.

Uh, those 3000 minutes go super fast, especially it's it's billable time, not wall time either. I was being all clever and. Doing my Mac build in one job. And then this iOS build in another job that iOS build in another job and they were all running in parallel. So that wall time-wise, the build happened quite quickly.

What I didn't realize. That giant multiplication that I was doing, I was paying for that giant multiplication. So even though it was only taking five minutes of all time, if I had five jobs running, that was actually 25 minutes build at 10 acts. That's 250 minutes. So that's fun. Um, Breaking it down. I certainly did spend a bit of money making all this work, especially for my first one, the very first app that I got, all this working on.

I had to do bill after bill, after bill, after bill. And in the end, I ended up spending roughly, um, I'm looking at numbers because you can actually download your detailed bill and everything. I spent about $20 and yeah, it's really not bad. Uh, Especially, because that is a real one-off it's been running for the last two weeks at my normal rate of development, which is slow.

And the trickle price is much lower, um, less than a dollar a day. So less than $30. You know, so it's fine. What happened was I just, you know, spent a million minutes trying to get these build scripts working, and that's why I recommend to everyone. Keep your build steps simple and do everything and scripts or Ms.

Build targets. You know, those are always fun to play with too. You can do it there too. But, yeah, I don't, I don't mind spending. Okay. I take it back. It looks like it's slightly more like twenty-five $30, but you know, one time I learned a lot and then the next app I did ended up costing me about $12 to get fully set up and running correctly.

And then the next app I did after that costs me $5 to get fully correctly set up and running. So you can see like the prices in my learning curve. 

[00:27:30] James: Yeah. No. I do believe they also allow self hosted runners. So you could have done all of this, like on your local machine. Actually paid get up anyway. 

[00:27:43] Frank: Right?

Absolutely. Absolutely. 

[00:27:48] James: That's how, as your dev ops works too. So I wanted to make sure that that was the thing that was still a thing. 

[00:27:53] Frank: Right. And you don't even have to go even that far. What you can do is execute your workflows on your local mission. And I could have done quite a bit of debugging at that level.

So when I say break up your workflows and the scripts, that's one way to do that. Another way is learn how to execute these workflows on your own machine. It takes a bit of setting up and you need those runners anyway. So it was just a little bit too complex, uh, in the future. It's much easier for me because I'm just going to copy and paste workflows from app.

And make minor changes. So it will be much easier. It was really just a learning curve going through all. 

[00:28:31] James: Yeah. Once you have it all in there, once you're sort of good to go. And I run into that same issue all the time. Like often, you know, in, in, in, um, app center, they can get 180 minutes of four hours of build time a month.

And there's no proration there. So that's not at 10 X, uh, for, uh, But maybe those are equivalent, right. Times 10. That's almost 2000. So, you know, pretty similar in general that you get for free. And then it's, you only have one option, which is going $40 up basically. And I've had to do that once I paid, you know, to do that once what it's taught me, Frank is as you smooth through this process, which is you have it all set up, it makes you much more conscientious of.

Doing full production builds on main versus doing feature branches in your only do slim line. And additionally, it also encourages you to heavily use branches and PRS. Uh, and maybe don't like, maybe don't put. Like, you know, I commit often, but maybe you don't push every single, every single commit every single time, like wait till the end of the day and push it to the server maybe, and then Nope, do that.

Um, that's also an option too. Or don't open the PR until you're actually ready, push no stuff all the time, but maybe don't do the PR that that's one thing I'm 

[00:30:02] Frank: thinking about. I went through all those debates. Once I learned the billing model and how much I was actually using a well a, I went back and refined all my build steps to be much quicker.

Uh, we will get back to signing others still more. I need to save outside, but no, let's go here because this was my biggest epiphany. James, I discovered here was the issue. I didn't like the don't push to main problem because it's just a habit. It's how I work. Anytime I've tried to do proper, I can do big PRS and things like that.

But if I just want to do a little patch, I just want to do a little patch. You know, I want to do it straight to me. Uh, and so I. Again, I know how I failed in the past and I know fancy branchy stuff makes me feel like I should be doing release branches, obviously, but I'm terrible at them. I just I'm bad. I, my good skills aren't there.

I forget how to do it. I'm just bad at them. So. I settled on a classic solution, time honored, proper software development. I'm going to call it James. I have rediscovered the beauty and the charm of the nightly. Oh, okay. Yeah. Yeah. Nice leads. So you're here. Push domain all day long. It's fine. You know, push, push, push, push.

What I do on those is a light CAI build. So I take the code, compile it, run some tests. It's not a full app build or anything like that. It's just proof that I didn't screw anything major up. Um, what happens otherwise on a schedule? Is that goes through and does the full, proper big device builds, which can take 40 or 50 minutes.

And it has changed everything. It has made my life so happy because what is the pattern I'm in now is work. You work, you work, you work, ease, stressy, stressy, stressy, getting features in, and then you're all. You're all tired at the end of the day and blah, you don't want to test anything, you know, you're just like, it's fine, it's fine.

We're going to ship it. And so you push to Maine and then you wake up in the morning and there's a lovely little notification on your phone. They're like, there's a new version of ICER because you're like, oh, there is, I wonder what happened, what changed? And you go click on it and testified as there. I love it.

I I'm in such a better mood in the morning and. Having these nightly builds is just fantastic. It's I love the separation of the QA pass from the dev kind of a mindset that you're in and it's worked out so lovely. And this way I don't have to stress out about how many minutes I'm using on GitHub actions.

[00:32:50] James: I like that because you know how long it, you know, how many days. Yeah, 28 to 31. And do you know how long it takes to build? Probably every night. So you can say, okay, well, do I have enough minutes based on this thing to do it now? It does. It, does it automatically run every night? No matter what, or do you, how do you flip that on and off?

Cause like, what if you're not working on a product, do you say, Hey, only, only do a new bill tonight. If there's new code. 

[00:33:14] Frank: Yeah. Yeah. That was a big stumbling block, honestly. Cause I knew, I knew what I kind of wanted was these nightlights. Once I had the idea, I thought it was lovely, but um, yeah. I didn't know how to implement it because what you really want to do is, you know, when you push to Maine, you want to register, you want to mark something as dirty.

You like, you want to say a build as needed. And then at night you want to check that dirty mark and say, okay, we do need a build. So it was just, where do I store that? It's literally one bit of information I need in the entire internet. James, I need to store one bit of information and I was stumped by where do I store this one bit of information?

Literally, one bit. Uh, thank goodness. I had to forget if it was a stack overflow or something, but I finally got a good Google search query and someone came up with a wonderful idea. So what you do is you run your nightly build script on a Cron schedule. It's out of actions works. So let's say on a 24 hour schedule.

So. What you do is you look at the history of the main branch and you see if there've been any commits in the last 24 hours. And that's your one bit of information. That's it. Easy peasy. If there has been a change in the last 24 hours, let's do a build and upload it to apple. If not doing it. Uh, retire.

And in fact, I run that script, uh, on Linux. So I don't have to pay the stupid Mac rate so that one just, uh, boots up and checks how things are going and then goes back to sleep. If it's, uh, if, if a proper bill doesn't needed. That's clever. 

[00:34:49] James: I like it. Isn't like it. 

[00:34:50] Frank: That's very smart. It's like a, it's the most clever part of the workflow file.

Like I said, I don't want clever in there, but I allow this one piece because it's, it's nice that I don't have to store any information anywhere. It can just query whether it needs to do a build or not. And I just copy and 

[00:35:09] James: paste it around. Yeah, that makes sense to me. I think that that is very advantageous to do with that.

[00:35:16] Frank: And it works out great. Uh, so I recommend everyone. I actually didn't do. I don't do like midnight builds. I do my builds around four or 5:00 AM because I know when I work quote unquote and all-nighter what it really means is I usually make it to about 5:00 AM and then I fall asleep. And so I know that 5:00 AM is like my hard deadline for the day and the bill won't kick off until then, because I don't.

Time pressure. I don't know what's broken in me, but even knowing that I need to be done by midnight was too much pressure for me. So I found 5:00 AM to be a good, no pressure. 

[00:35:52] James: Well also, you know, when you think about it, there's probably many people that have similar jobs set up that are all kicking off at midnight and all those, those little machines are all going to be so busy.

Yeah. And then you're going to have to wait 

[00:36:05] Frank: until. Yeah. In fact, uh, recommends when you're setting up your Cron job, like don't schedule it for the zero. With of the hour. Mine runs at like 4:43 AM, 5:13 AM. You know, just the most random times to try to so that you're not competing with everyone. Yeah. Pro tip.

[00:36:22] James: Yeah. All right. Back to signing. What did I forget? 

[00:36:27] Frank: Oh, there there's one last important part, a part that I would always screw up. So I'm you were a D we're developers and we're, we're having a hard time getting it running on our dev device or on our dev machine or whatever. And so you're fiddling with the code signing stuff within the ID.

And within the project file and inevitably I break CIC D with that, it just happens. It's it's accidental, you know, but you, you change a setting real quick and you forget to change it back or something like that. So hack big hack. Number two, the, I highly recommend for everyone and I always forget about this, but you can pass.

Project properties at the command line at build time. And so what I started doing was passing the enable code signing equals true on the command line code sign key equals apple distribution on the command line. Build IPA equals true on the command line and those override, whatever the heck garbage happens to be in your project file at the time and does the right thing.

So this means I can mess around all day with the settings and visual studio and not worry about it breaking my actual production build. Obviously I don't want to be doing that. I want to keep everything in line, but that way it just. I, I have so many red axes because of stupid little code sign, things like that.

And you just fix it by slash P colon and Naval code signing equals true and et cetera, whatever else you need on the command line. 

[00:38:03] James: Clever, clever Frank you're clever, clever guy. I like it 

[00:38:08] Frank: works out beautifully. 

[00:38:10] James: So now you have it, it ships it to test for. You're doing stuff and that's the end of the CD, right there.

There, you don't have like another gate that's tells it to toggle on and actually release the app. Right? You're not that 

[00:38:24] Frank: risk. Yeah. So I, I have the smallest gate of, I need all the operating system builds to succeed before I do, uh, an upload. So I, I gave everything on success. Um, which I was messing up at first, cause like it would upload the iOS version if the iOS build succeeded, but not the Mac version.

And I decided, sorry, going back to the very beginning of why am I doing this? Another thing that I kept running into was my platforms. We get out of sync with. And so I'm really looking for the CD to help me keep my platform versions in sync. So I'm not just simultaneous releasing, but everyone's getting the same version set and everything.

Um, so I wanted to make sure I'm, I'm not releasing on one platform without making sure all the platforms can come along for the ride. Uh, that's my one big gate there that 

[00:39:19] James: that's. Especially if was kind of fascinating. Yeah. I've, I've gone down a path where I'm not necessarily sh SIM shipping, new versions of iOS and Android.

Exactly. At the same time, because now I'm introducing a lot more like in-app purchases and like, they involve a lot of testing. So I'm kind of rolling them out a little bit differently at different times. I'm kind of okay with. But it makes sense if you have an iOS and Android version of the same app that you need to make sure that those things are shipped out together now, is there, there's not a test flight for Mac yet, or is there, do they announce it?

Is it a thing or not? 

[00:39:58] Frank: So I should rewind on all this. That's really what also got me into all this is there is test flight format now. You need Mac iOS version 12. Uh, what's it called? The latest, whatever latest you need. Latest. Yeah. Um, but golly, gee whiz. It works great. I, I did a CD. Uh, it uploaded to the test flight.

I went over to my. Uh, it has version 12 and it got the test flight. It downloaded the app and ran the Mac version right there on the M one processor, Eva worth. And that was a dotnet six built. So, yeah, that was really cool when that happened. And there was no code on that machine. That was a clean machine.

I was so happy when that happened. That's when the system finally all came together, you know, on that first download, 

[00:40:53] James: I truly need to. No, no, I truly need to go and figure this out from my Mac app, especially because it is one of the pain points that I have and my, my windows app too. But I do really like how that seamlessly transition for you.

And that was the motivation because like, you know, getting that out there at the same time is something that I've been struggling with. And for me, it's been a struggle because. I have a lot of all my Mac stuff set up on my old, old machine and I don't only want to touch it. And, you know, I don't really want to upgrade stuff, but it sounds like here is just it, you know, it brings more consistency to, to this whole thing.

So I need to get on it. I feel like I've, I feel like on my mobile side, I'm I'm on there, but on the desktop side, I'm way behind. That's what I feel. 

[00:41:43] Frank: Yeah. And I mean, rightfully so my dev machine is still Mac iOS 11, so it's a little pathetic. I can't even run test light on, on my dev machine, but I've been a little bit nervous to upgrade.

I should get over that. I should upgrade. Um, but you know, things are changing so fast in the macro. I like having a few machines on different versions, at least for testing. It's nice that my little laptop is a version head, but it's really, I wish apple had released TestFlight for Reno version 11. It's all I'm saying, but it's nice that they got it out for 12.

So moving on in the future life is going to be pretty good for testing on a Mac. I've had one issue, James, I don't want to make it all sound. It hasn't been perfect. It's each one of those builds steps was pain and torture, figuring out I told you how much money I spent on minutes and all that. Um, I have one last obstacle that I haven't gotten over and I'll even reach out to the audience.

If any of, you know what this is, I might even put this on Twitter later this week. I have to figure out what's going on. So when you're in test, You can release internally, which is what I'm using, because it's, you don't have to get approval from apple. Is that what you do? 

[00:43:00] James: Correct? Yeah. So I have, I have that set up.

There are also groups that you can set up like groups or external testers. Yeah. And then that. I have to be approved. They take like a few hours or whatever. I think 

[00:43:14] Frank: less scan them. I just have to make a PSA because I was an idiot and I didn't know something important here. I use two email addresses. I use a company address to do all my appellee's stuff because it's company stuff, it's all registered through my company and all that stuff, but all my apple, the stuff I do through another email address.

So I have two apple IDs. Uh, the, the company one has been an internal tester forever, but it didn't matter because I'm not signed in as that person on any of my devices. And so whenever I wanted to test my app, James and I sound so stupid right now, just in reflection, I would do an external release, which has to be approved by apple.

It takes a lot of time, but also that I could get it onto my personal account. I am such an idiot because finally I got the guts to just go add my personal account to the team. Yes. Yes. I feel so stupid because now I can get, I get instant builds the moment they're uploaded and moment that, or whatever virus checked or whatever they're doing with them, you get the instant build right on your phone.

Don't be me. If you're still doing external testers just for yourself, don't do that. Add yourself to the team. Be smart. Don't be like me. External testers are still important obviously, but, um, I just, I can't believe I was making that mistake for so many years. 

[00:44:43] James: That is correct. Yeah. You can have 100 internal testers and 1000, oh, sorry.

10,000, uh, external testers. So you only really need. If you need that many. So if you need 10,000 people and like you can have a public link as well, and you can limit that stuff, which is cool. Um, yeah, that's hilarious. I have three internal testers, which are all my different, different accounts, different accounts to debit cards, all the different, anything that might be on any of the different devices I have.

Cause I was like, I was like all of them, please. Yes, that is, that is absolutely a. 

[00:45:17] Frank: Key time-saver because for some reason, like proper app store review is faster than test flight review. For whatever reason. 

[00:45:26] James: I don't know. Now that you are shipping, 

[00:45:28] Frank: hang on. We're not quite, we still have a problem, but okay.

Continue. 

[00:45:32] James: Oh, I was going to say, now that you're shipping both of these into test flight, apple, just change apps or connect by the way to submit, to submit your apps for review. So since you have an iOS and a Mac app, you now. Add apps that you want to be reviewed into a bucket, and then you submit that bucket for review.

[00:45:53] Frank: Oh boy. Yeah. Sounds fun. Yeah, you'll see. It's fun too, because for some apps I have a shared apple identifier. What do they call it? A skew and some I don't. So yeah, can't wait, can't wait. It's going to be fun. Um, but no, I got to tell you about one last problem. And this is a problem with my build systems.

I'm not sure exactly where the issue is. So all this internal testing is working just fine test flights, working just fine. But I went to do an external test cause I'm on the ship and I want some people to look at it and I got the most mysterious error from app store connect. Yeah, it says this build is using a beta version of X code and can't be submitted.

Oh no. Uh, okay. I have built logs saying it was using ex-co, you know, whatever the heck version we're on right now, not a preview version. So something is not getting set. Something's getting set to the wrong value. I don't know exactly where. So there's a little bit of, a little bit of investigating. I still need to do and understand what's going on with, uh, my bills here.

So it's sad. It's sad. Cause I'm like 99% of the way there. You know, I even, I have working test flight builds, working on different machines and all that stuff, but for some reason there's still just one little thing wrong with my bill. 

[00:47:18] James: Did you try to, I think there was a good hub action where you can select or set the version of X code.

Right 

[00:47:26] Frank: now, this was going to be my last topic, so that great segue, James. Thank you. You're welcome. So being back to maintenance, um, it's already happened, uh, Xamarin didn't update that changed some knowability stuff I compile with knowability error. Checking on the get hub version of Xamarin was different from my dev version.

So I didn't notice the error, you know, I don't update my diversion that often. So, uh, I just said, notice the era, but it broken CIC D and this is what kills me. This is what it breaks my heart about CIC D. So everyone knows the answer to this. What you have to do is lock the versions. You just gotta start version, locking everything.

And I was resisting doing that roughly with the idea of, I want to live in the future. You know, I just want to adapt to the future, but, um, Eh, eh, eh, uh, I'm probably gonna start version locking at least X code and 

[00:48:26] James: yeah, I just found this awesome set up Xamarin. Get up. Action. I. 

[00:48:32] Frank: I believe that's the one I was looking at.

Yeah, it's fantastic. Uh, let's see, specify exactly what you want to specify your X code version macro, uh, Xamarin Mac versions. I'm an iOS version and version Santana Android version. And I somehow magically go get some great. 

[00:48:48] James: Yeah, there's a. There was a application, maybe use it on the hood called boots that John peppers wrote.

And that was like very similar, but this might be doing something completely different, but yeah, you know, that, that locking is important because the other aspect of app center and other services that are specifically tailored for mobile application development or something like that, they know these things in mind, right?

Where GitHub actions or Azure dev ops or the generic, like build anything, which is great. But. It has these other conflicts perhaps, but I would like to see in the future is just a beautiful template that says, add a thing and does it, that'd be so. 

[00:49:26] Frank: Yeah. Yeah. Um, I'm going to build my Uber action one of these days, but, uh, until then, yeah, I think hopefully version locking, uh, Xamarin and X code will be helpful when doing dotnet six.

You already do that because you already download a specific version of dominant six. So actually, hopefully some of these problems will go away in the future. When we're doing it that way. So anyway, one last tiny little stumbling block left. I really, really don't want to right. Click deploy this app. You know, I want to deploy this app from CD.

I want, you know, the version on the store to be from CD. And so I'm going to try to work through this one last version, but it's, it's a little bit frustrated or one last error. It's a little bit frustrating to hit a little hurdle at the end, but keep working through. Overall. I am so satisfied with myself, especially like I said, I did this on multiple apps.

I kept talking about ice circuit here, but each app had its own little issues and all these little things, but the learning curve was nice. And I'm just so happy that I have it running now. 

[00:50:32] James: That's awesome. And also I got to say. That Maxime individual that made that those get up actions works. I get up. So that's cool.

Perfect. On the official official actions. That's so cool. I liked the Dre, you know, to me, give actions has been around for a while, but just like any thing I'm like, I'm. Complex mobile development. There's a whole bunch of dependencies and there's dot net versions. There's Xamarin versions. There's mano versions.

There's excode versions, there's Android dependencies and you're like, ah, there's signing certificates. So I'm glad to hear that this thing has come a long way and I'm really excited. Uh, give it a try for, especially for my Mac version. They're really need to get on it and actually do it. That's what I, I think I need to do that's for sure.

So yeah, hoof does cool. 

[00:51:18] Frank: I like it. Long episode. Sorry everyone. It was on CD, but I finally, I finally got the religion and had to talk about it. So thank you for sticking through 

[00:51:27] James: get hub actions. From an end to end with GitHub actions. That's where I think we're going to call this episode or something that you let me know.

I can do it. Even Frank can do it. I think podcasts need little subtitles. You know what I mean, little faith. I know that there's descriptions, but I think it'd be fun. Kind of like we get in the apps or, you know, apple give us 180 character, a hundred. What is it? 80 karat. It's 80 characters by the way.

That's all you get. So, yeah. Oh, Frank. Well, thank you so much. For going through the hard problems of getting this done. At basically tell you to share your Yammer, steal it. So we'll go from there, but let us know where you're at in your, uh, CACD are using GitHub actions are using, uh, pipelines. Are you using something else?

Fine? What are you using? Let us know. Or you just buildings, right? Click, publish, and archive. And that's fine too. Just let us know what you're doing. Right into the show. Good emerge conflict out FM, or hit us up on Twitter at James Watson. I know an app for Clara, and you can find those in the show notes below.

So until 

[00:52:26] Frank: next time I'm James Monson Magno and I'm Frank Krueger. Thanks for listening.