Let's talk about managing your serverless functions between different environments. Here we're looking at the Lambda console, and you'll see that all the functions we've been deploying so far have this local in it. Serverless is our app name, local is our environment, and then it shows the class name. By default, Sidecar separates your functions based on environment. I'm going to delete these two just so we can look at the helloWorld one only. Now we just have our helloWorld function from the local environment. Let's dive into this a little bit more. If we look at our .env file, we see the app name is serverless and the environment is local.

If we look at our .env file, we see the app name is serverless and the environment is local. That's where this comes from and that comes from. This is just the description. What actually matters is the function name. You'll see sc, which stands for Sidecar, serverless, local, Sidecar, hello world. We can control this name a little bit in the function itself. We go to the hello world function. There's a name method that you can use. Let's look at what it is by default.

There's a name method that you can use. Let's look at what it is by default. By default, it takes the fully qualified class name and replaces app. Since almost every function lives in the app namespace, it's not super helpful to see app. If you want, you can change this to something a little bit shorter and nicer. We'll call this helloWorld. We'll make sure that it's registered in our configuration, so we'll turn this guy back on and we'll deploy again. deploy --activate. You can see it says deploying that class as, and there's that full name.

Deploy --activate. You can see it says deploying that class as, and there's that full name. You can see now it's hello world. Looking in the console, we now have two functions. You need to be careful that when you change the name, you're creating a new function. That may be totally fine. It's just something you need to be aware of. The same goes for environments. If we change our environment here to staging and were to deploy again, you see the name has changed to staging hello from local hello.

If we change our environment here to staging and were to deploy again, you see the name has changed to staging hello from local hello. The environment, it correctly picked it up as staging versus local. We should now see a third function in here. There you go. There's staging hello world. We need to be able to develop our functions locally, but not have them interfere with our production functions. What happens when you have more than one person working on a team? If you have more than one person working on a team, all of their functions are going to

What happens when you have more than one person working on a team? If you have more than one person working on a team, all of their functions are going to be local because everyone's working in their local environment. You don't want to change your entire app .env to something like errand.local because throughout the rest of your app, you're potentially looking for local environment. We're going to change this back to local and then let's look at the sidecar configuration file. The .env defaults to sidecar.env, but if that's not present, it falls back to app.env. When you're working locally, you can plop, let's scroll down here, you can put a sidecar.env of errand.local.

Every team member can set their own sidecar ENV and they won't be overriding each other. There's one more way to control the environment. This command that we've been running, sidecar deploy, let's look at the help for this command. The help for this command has an ENV, so we can, instead of controlling it by actual environment variable, we can override it on the command line. We'll say ENV=errand CLI. Look, we get a brand new environment, errand CLI, and a brand new function, errand CLI. This method isn't as useful when you're running things manually, like when you're deploying from your local environment, because it's kind of a pain to have to always put --env=errand CLI, and if you forget it, you accidentally overwrite someone's function.