Deploy Slack Apps Safely From Sandbox to Production (Full Transcript)

[00:00:00] Speaker 1: Do you want to see how Slack fits in with the software development life cycle? Watch this. Hello and welcome back to Slack School. My name is Mike Reynolds. I'm your host. And today we're going to talk about how to actually deal with taking the app that you built in a sandbox and getting it into production through a good software development life cycle. Of course, there's a lot to cover in this topic and there's more than one way to do it. So I'm going to go over a very general example where we start the build in a sandbox and then we move that build into production. That is the shortest development life cycle that you could ever have. I know someone saying, well, you could build it in production. Don't just don't do that. Just watch, watch. It's not that hard. You don't have to build in production. Think about all the things you won't break. Yeah. Okay. It's okay. Today's example is going to be a very simple example where the only thing we need to deploy is our app into Slack. Next week, I'll show you a more complicated example where we have to deploy something into Slack and we also have to use GitHub actions to deploy backend codes somewhere else. We'll look at that example next week. For now, we're going to go with a simple example where we deploy into our sandbox, then deploy into production. Let's get after it. All right, we're going to begin here. I've got a new function that I've written. Check if a user is in a channel. This is going to allow us to, in a workflow step, check and see if the users are even added into a channel. It's a simple function, but now we need to get it deployed. We know we're going to start by logging in. So let's do that. I'm going to type Slack login and it's going to give me this code, which we're going to copy and I'll jump into Slack. And then again, you can do this anywhere you like. Paste the code in and hit enter. It's going to want to confirm, are you sure you want to grant this access? We absolutely are sure. Copy the challenge code and close that window. Back into my VS code and enter my challenge code and hit enter. Now I've successfully authorized my way in. Now let's say I've already done all of the testing. I know I'm ready to deploy, so I can skip the Slack run step where I would then go check in my org, make sure everything looks good, and just go straight to the deploy. Here it's going to want to know, is this exactly where we're going to deploy this? This is the environment I want to use. So I'm just going to hit enter. And the Slack CLI is going to go ahead and deploy into my environment. And we're done. So now I could go in here and test my new app, make sure that it works well with my new function. Let's say that we know that our app is good. We've done all the testing in this environment that we want. So our work in the sandbox is done. I now need to promote this up into production. If you're going to be deploying using the CLI, it's going to look very, very similar. And I'm going to give you some best practices. The first one is that we should log out of our sandbox. You don't have to do this. I recommend it because I have a perfect track record of never deploying something into the wrong space because I try to only be logged into one space at a time. You don't have to do that, but it works well for me. So I'm going to go back to my Slack CLI. I've just deployed, so I'm going to log out. Easy peasy. We're done. Now I need to get logged into my new environment. Now notice I haven't done anything else to VS Code. I still have my app code up and it's still ready to be deployed or anything else. I just need to log in first. So I've logged out of my sandbox. You guessed it. We need to log into production. So I'm going back to Slack. I can see here that I'm in my developer sandbox, and I'm going to switch to my cool cats org. Now this is a production workspace, so we just need to repeat these steps. I'll start by Slack login, we'll copy the challenge code, come back, and we can paste that anywhere. We're going to confirm our settings, copy the challenge code here, go back to VS Code, paste that challenge code, hit enter, and now we're up and running. I'm logged into production when a moment ago I was logged into the sandbox. Once I've logged into production, I need to deploy the app, but we've got to be careful when we do this. I'm going to type Slack deploy, and you'll notice my terminal wants me to use this existing app and it's still pointed to the sandbox. That's okay. We just need to choose new app. I'm going to hit my down arrow and then hit enter. Now it's going to say, great, well, where are we logged into? I'm logged into my cool cats org, and that's exactly where I want to deploy this to. So I'll hit enter here. Now it's going to go ahead and run through the deploy and everything will work out just fine. Let's say you accidentally didn't select new app. Because you've logged out, you're going to get an error saying that you are not already authenticated into the environment. That's why I like to log out. You'll still see that as an option. We're just not going to choose it. Well, there you have it. Deploying with the Slack CLI is really easy. Remember that once you're done building, go ahead and log out with the code Slack logout. Go log into your next up environment with Slack login. When you're ready to deploy your app, push it with Slack deploy. It's really all you need to know. Most of us are going to be using a chain of environments that is longer than just one sandbox. After all, when I do things in Salesforce, I almost always have at least four environments. We typically build in a developer environment. We move that up into user acceptance testing to make sure that my users actually are getting what they asked for. I tend to prioritize that first over QA. After user acceptance testing, I send it to QA. Once my quality assurance has reviewed everything that we're good to go, then I'll consider putting it in production with the next release. Oftentimes that involves a staging environment. It might seem like a lot of environments, but the number of environments you need to deploy are going to be based off of your organization. And the order you put those environments in is going to be based off of your organization. For example, I said I like to put user acceptance testing, UAT, in front of QA because I had more users willing to help with testing than I had time with my QA engineers. So I put user acceptance testing first. That meant that my QA engineers never saw anything that wasn't what my users ultimately And that helped me be a little bit more efficient. You can always build your software development lifecycle to work for you and your organization. And it doesn't matter how many times you move from one sandbox into production or from one sandbox into another sandbox. The fundamental process is going to work exactly like what I just showed you. It's short, it's simple, and it works every time. Let us know what you thought of the episode by jumping into the Slack Community workspace at slackcommunity.com, jumping into the Slack School channel, and letting me know. Or give me an idea for a future episode. We'll see you next time. Oh, hey. Good job today. You too. Good job. You stayed off the desk for so long. That was great. Woo. It's short, it's simple, and it works every time. Except for when I break the code, then it doesn't work at all.