Hey everyone and welcome to Developer Tea my name is Jonathan Cutrell and today we're going to continue our discussion on the 12 factor app. Number two is dependencies and number three is config. Number two is referring to explicitly declaring and isolating the dependencies of your application. And number three is referring to storing the configuration variables of your application's deployment in the environment rather than in the actual source code. So we're going to dive right into number two, which is dependencies. But before we do that, I want to go ahead and make the disclaimer that 12 factor app is something that came out of the people at Heroku. Now, Heroku is not officially sponsoring this episode or any episodes of Developer Tea currently. So we are not trying to push Heroku as a platform. In fact, the 12 factor application can be actually implemented on any given platform. Heroku just happens to support this idea. And there are some good ideas in the 12 factor app in this kind of methodology in each and every one of these 12 factors. Number two is dependencies. And I want to jump straight in and go ahead and get started explicitly declare and isolate dependencies. This is incredibly important because it keeps you from bringing in dependencies into your source code. And it also prevents you from trying to monkey patch or overwrite those dependencies. This is a very useful concept that has been used over and over successfully in many, many applications. I can't overstate this. Jim files and package.json, Bauer.json, whatever you're given, manifest file is. Those files are incredibly important and you should be doing this isolating your dependencies. Now, what does this exactly mean for people who are relatively unfamiliar? Well, basically any given code base like we talked about in the last episode of Developer Tea. And given code base usually relies on something third party. There are very few code bases that are actually built from the ground up with no external dependencies. And this is especially true if you're working on backend applications, but it's also true more and more for front-end applications. This is exactly why things like Bauer came along. Of course, node is taking care of this with the NPM, just the built-in package manager for the most part now. But we also have things like gulp and grunt and all of the packages that are necessary to use from NPM for front-end. And we're specifically talking about web development at the moment. But typically there are going to be package managers throughout pretty much every language. It doesn't matter if it's web development oriented or if it's system oriented and typically each and every one of those package managers has a way of creating what's called a manifest file. And what a manifest file does is it allows you to determine what things your app needs to run. For example, if you are creating a Rails application and you need to allow users to sign in, but you don't want to hand roll all of the things that are necessary for a user to sign in, you can add the devise gem to your gem file and simply run bundle install after you've added it to your gem file. Even Rails itself is added to the gem file because you need to have Rails in order to create a Rails application. If you're using PHP, you may want to check out something called Composer, which is a PHP package manager. So taking a bit of a step back, the basic idea is that if you have third party code, if there are libraries or perhaps frameworks that you depend on for your application to work properly, then that code should be managed through something called a manifest file. And when you are starting your application on a new machine, when you actually deploy your application to a new end point, then you ensure that that end point actually has run that manifest file. Perhaps the most important benefit of doing it this way is that you can take your code to any machine and run that manifest file and be sure that your code will work if that manifest file has run properly. In other words, if you declare all of the things that your application relies on and then you install all of the things that your application relies on, then it is a very high likelihood that the system that you are running your application on is ready to run your application properly. And added benefit to this is that you aren't going to be committing a large amount of code that you aren't even changing. That you won't be adding all of the third party code to your repository, which would make your repository unnecessarily large. Instead you allow all of that code to live on the remote hosting servers that that code base is actually relying on to distribute whatever their production versions of their code base are. And your manifest file simply references those end points. This makes the overall size of your code base much smaller, which makes it much easier to share with your teammates. And it allows you to update those external dependencies much easier. You simply change the version number in whatever that manifest file is. A great example of this is the package.json file that node applications use. You can simply use the semantic version number, change the version of the third party tool and run the install for that manifest file once again. And you'll have the newest version of that tool available to you. Of course to execute this, you'll want to take a look at the Git Ignore documentation. This will allow you to ignore the folders where that third party code is being installed. If it is being installed in the same folders as your application code, this is particularly relevant for front end developers and those of you who are using node because wherever your package.json file actually is living is where your node modules will be brought in. So the package.json file and the node modules folder are going to be in the same directory. You're going to want to make sure that you ignore the node underscore modules folder in whatever your version control system actually is. I'm assuming you will be using Git and so you'll want to check out the Git Ignore documentation. We'll include that in the show notes as well. I'm going to take a quick sponsor break and then I'm going to come back and talk about number three, the third factor in the 12 factor app, which is the configuration, storing your configuration in your environment. We'll be right back. Thanks so much to today's sponsor harvest. Do you know where all your time is going? Do you know how much time you're spending on each feature or tweak or bug fix for every client that you work for? You probably don't if you aren't tracking your time. Now harvest is a tool that helps you track your time. It's built for developers. It takes the pain out of time tracking for you because with their official Chrome browser extension, you can start a timer directly from the issues that you have already in Trello or GitHub or Gira. Now not only will you understand how much time you're spending on client work, but you'll also be able to turn your billable hours into an invoice from harvest in minutes. Harvest integrates with PayPal and Stripe to make it easy to get paid. They also have iOS applications so you can take your timers on the go. So you can create a free 30 day trial at Git Harvest.com. Now after your trial, you can also use the Developer Te Code teatime to save 50% off your first month. Of course, the link and the code will be in the show notes. Thanks so much again to harvest Git Harvest.com. Thank you so much for listening to Developer Te today. Before we jump into number three, the configuration being stored in the environment, I wanted to ask you if you will take just a few minutes to leave a review in iTunes. This is an incredibly important part of the show's survival. We need people to know about the show. And iTunes algorithms, you guys are all smart enough to know this. iTunes has a lot of algorithms that determine how shows are displayed to people who are looking for them. And one of the most important things for the show to be able to grow and for the show to be able to continue on is if you leave a review. The reviews and the ratings are incredibly important to that algorithm. So if you don't mind, please take just a few minutes. The link will be in the show notes. You can go directly to leave a review for developer on iTunes. That will be such a big help. So let's jump into number three, storing the config in the environment. Now the basic test for this is you should be able to push your code to an open source environment and not worry about any of your application specific credentials being shared. So API keys, passwords, any kind of personal information that you have stored in your source code that should be moved out of your source code and into the environment. And the reason for that is because there should be an infinite number of endpoints that your application is actually launched on. This means that your development environment, your testing environment, your staging environment, your live environment, and someone else's environment. All of them could have the same exact code base and read environment variables. In other words, variables that are set specifically as files or as session variables on the environment, the execution environment on the server that you're using. That is where that information needs to be held. It's the most secure in that location and is much less likely to be accidentally shared by sharing your code base, by publishing it on something like GitHub. It's also much less likely that someone would be able to read the environment than to be able to read a given file on your server. So perform that test, perform the test of looking to find any kind of sensitive information or personally identifiable information in your code, but not only sensitive information, but code that would disallow you from immediately launching your application on another machine with new configuration variables. That configuration should not be in a flat file. It should be at the very least, it should be in the flat file.imf if you're using something to read that file, but even more secure would be if it was in the environment variables of whatever the execution environment is that you're using. For example, we'll refer to Heroku. Heroku allows you to set these specifically using their command line interface tool. So always keep your code in that safest state where you can always share it and nobody will be able to see your personally identifiable information, your API keys, your passwords, even email addresses. These are the kinds of things that you want to store in your configuration and that configuration should not be in the code base. This should be specifically stored in the environment. Thanks again for listening to today's episode of Developer Tea and thank you to Harvest. If you are like me and you have a difficult time tracking your time, Harvest makes that just a little bit easier. You can click a little timer from your Trello board or from a GitHub issue. Harvest knows how to track that issue and gives you a detailed report. It integrates with all your payment systems. Go check it out getharvest.com and make sure you use the coupon T time for 50% off your first month. Thanks again to Harvest and thank you for listening to today's episode and until next time, enjoy your tea.