« All Episodes

The Twelve-Factor App, Part 1: Codebase

Published 8/17/2015

This week, I'm going to go dig into a few of Heroku's Twelve-Factor Application Model. Today's episode will be focused around codebase also known as a repository. We'll talk about understanding codebase, implementing techniques and deploying.

I'd like to note that you can implement this model on any deployment platform, not just Heroku. There's even a way to create a Heroku like docker on Digital Ocean. It's called Dokku.

Today's Show is brought to you by: Hired

Hired is a free, no obligation resource for job searching. Just answer a couple of questions, sit back and let job offers come to you. If you or someone you know is looking for a job in design or development check out hired.com/developertea to get a $4,000 signing bonus when you accept a job.

Geting in Touch: If you'd like to automatically receive updates to the show you can subscribe to Developer Tea in any platform you choose. You can also follow me on twitter @developertea or the spec.fm network @specfm to get instant updates on this show along all the other shows in spec.fm.

I hope you enjoyed this episode, and until next time,

Enjoy your tea!

Transcript (Generated by OpenAI Whisper)
Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and today we're going to be talking about 12 factor apps. Specifically we're going to be talking about one aspect of the 12 factors that's I guess the first factor and that is code base. But before we get into that I want to say that 12 factor applications this is an idea that was promoted and created by Heroku. Heroku is not a sponsor of the show but this idea is you can find a summary of it on 12factor.net and Heroku has built a pretty large infrastructure around this idea. I guess another thing that needs to be mentioned is that the 12 factor application really fits the deployment model that Heroku has available kind of out of the box. But of course you can implement this on any other deployment platform that you would like to use including a sponsor of the show Digital Ocean. Digital Ocean there's a lot of others that will allow you to deploy in this way. In fact there's even this is I'll put this in the show notes but there's a way of creating kind of your own Heroku on Digital Ocean. It's called Dokku and it's through Docker the idea is to have a kind of a homegrown Heroku Docker. Of course you wouldn't have all the features that Heroku offers but it certainly is an interesting proposition for those of you who would like to just spin up a droplet on Digital Ocean. So check that out and it'll be in the show notes. I'm going to read a little bit from 12factor.net just to give you guys a little bit of an introduction. 12factor app it says in the modern era software is commonly delivered as a service called web apps or software as a service. And then the site goes on to give a list of the 12factor apps kind of methodology and why it thinks that it's important to have these 12factors. And I think these are good and I'm going to go ahead and read you the 12factors but we're only going to talk in depth today about number one. Number one is code base number two is dependencies number three is config configuration. If you don't know what that means. Number four is backing services. Number five is build release run. Number six is processes. Number seven is port binding. Number eight is concurrency. Number nine is disposability. Number 10 is development and production parity. Number 11 is logs. And number 12 is admin processes. So a lot of these are pretty specific and we hopefully at some point we'll be able to go over each and every one of them. Today we're only going to cover number one in depth. And that's code base. But these other ones they really don't mean a lot without you actually going and getting a little bit more context. So go check it out at 12factor.net. Number one is code base and that's what we're going to be talking about in depth today. One code base tracked in revision control with many deploy. Now I want to go over some of this terminology that you'll find on 12factor.net. In case you aren't familiar with it. And there are people who are listening to this show who perhaps have never been exposed to version control or the idea of deploying an application at all. So I'd like to give you kind of a working definition of what these things actually mean. A version control systems basically they track the changes that you make to your code and they allow multiple people to work on the same code base. And we'll talk about what a code base is in a second. But to basically work on the same code at different times. And then they all contribute to that version control system using typically what is called a commit. Now commit takes what you have done since you pull down the latest things that other people have done. It will take what you have done and package it up into a commit. And there's some data that goes along with that and you push it to an end point. And then other things can happen with that code at that point. Perhaps your other team members will pull it down and they'll perform what's called a merge, which is where they take your code and they put it together with the code that they've been working on. And sometimes there are errors there and you have to manually fix those. But usually good version control systems, for example, perhaps the most popular one right now is Git. Git will try to merge things on its own. Okay, so we're going to take a breather here and talk about something totally different from version control. And that is jobs. If you want to get paid writing clean code and you know, respecting the practices of the 12 factor app and actually pushing things to version control, if you actually want a job in this industry, then hired.com can help hired is today's sponsor on hired software engineers and designers are able to get over five job offers in a single week. And each of these offers has salary and equity up front. And they have both full time and contract opportunities from over 2,500 different companies from 12 major tech hubs around the world. On top of that, it's free to sign up. You never have any obligations and they offer signing bonuses if you actually get a job. Now usually that bonus is $2,000. But if you use the link that I'm going to give you from today's show notes, then you will actually double that bonus to $4,000. Check it out. It's hire.com slash Developer Tea. Now, even if you aren't looking for a job, but you know someone who is, you can refer them to hired. And on top of the fact that they will get a bonus and they'll thank you for helping them find a job, you will also get a referral bonus. That's a $1337 bonus just for helping someone else find a job. Here's a little pro tip. You may want to share the link from the show notes with them because it will give them that free double bonus if they do end up getting the job. Once again, that link is hire.com slash Developer Tea. Now, speaking of jobs, the really awesome thing about listening to the show and learning about things and simple as code deployment and learning all of this vocabulary, all of this stuff is going to make it much easier for you to pursue this as a career. You're going to get some information on this show that will help you become more employable if you don't already know this information. And why is that? Well, it's very simply because being familiar, even with just the vocabulary, understanding what something means, that puts you just a little bit ahead of the next guy. If you understand the difference between react and reactive programming, for example, go back and listen to the episode with bin Lesh and I bin Lesh works at Netflix. If you understand the difference between those, then when you're having a conversation with a potential employer about the two things, and you know the distinction between the two, that employer knows that you care about your craft and that you've invested the time to learn the differences and to learn the nuances of computer science and to learn the nuances of development. And that's exactly why I make this show because even if you don't immediately start using each and every one of the different 12 factors in your applications, you now have this vocabulary. You now can have a conversation about these things and when that conversation occurs, you're ready. You have some context for what each of these things means because the truth is you never know exactly when those key pivotal moments and key conversations are going to occur. It could be that your mentor is walking into the same coffee shop as you or a future employer is sitting at the same table as you are at a given meetup. Who knows when these conversations are going to happen, but you know that you will have the necessary vocabulary when they do. So now let's talk about what a code base is. A code base is one specific applications code and that's all it is. A code base cannot contain multiple applications and a code base cannot be shared on multiple applications. The sharing of code should instead be done through a package management solution. Now these are all, once again, more terms that you will need to find for you, but essentially there are different types of software that you create. You can create an application that takes a bunch of other software, perhaps third party package software that you are using for your application. An example of this would be Rails or if you're only working as a front end developer, jQuery and perhaps there are, you know, if you're an iOS developer, there are Coco Pods that you're pulling into your project and your application can use all of these different things and you can write your own application code on top of that. That would be considered your code base, all of that together. Now if you wanted to include your entire application in another application or if you have code in your application that you want to include in another application, but you don't want to include the whole thing, and under the 12 factor methodology, you would want to package up the parts that you want to share, but a code base is not intended to be shared with other applications. So let's clarify that could have gotten a little bit convoluted. A code base is the code of an application, including third party pieces of code that might have been pulled through a package manager. An example of a package manager would be something like Bauer or perhaps NPM, another example would be Bundler and there's operating system level package management solutions such as HomeBrew or apt Git. All of these things are intended to help you manage pulling in what we call dependencies, which is third party code that you want to use in your application. Now typically your code base, specifically the code that you keep in version control will not include the actual code from those third party tools, but instead will include some sort of specification file that explains that your code depends on those other third party solutions. In Rails, this is the gym file. With node projects, this would be the package.json file. Even something like a make file could have external dependencies that are pulled in and used to make or compile a given tool on your system. Typically when someone is talking about a code base, they're referring to wherever that code is hosted on a version control hosting system. An example of this is GitHub. This is once again probably the most popular example. So go check it out github.com if you are unfamiliar, but GitHub is the code base that would be considered where your code base actually lives. In fact, each of the developer's individual personal computers, like your actual MacBook or whatever it is that you're using, that is considered a deploy under the 12 factor system. So the idea is that you can pull to your computer just like you can push to a production computer. Another term that you will hear used for code base is repository. Repository is simply where the code goes when you commit it. When somebody commits a piece of code and they push it to a remote repository on GitHub, that means very simply that they are pushing the changes that they have made to the code base. So to sum up the first factor in a 12 factor app, you should have a singular code base, one that is tracked in revision control, and one that everyone has access to on your team, and that you can actually deploy to an infinite number of endpoints, whether that is a given developer's computer or perhaps a staging server or even the actual live production server. Every endpoint should read from that singular code base that is managed with source control. Thank you so much for listening to today's episode of Developer Tea. I appreciate each and every moment that you spend listening to this podcast. Of course, if you want to automatically receive updates about Developer Tea, you can always just subscribe to the show in whatever podcasting application you use. Now, what you automatically get the show three times a week. Thanks again today's sponsor hire.com. If you are a software engineer or a designer where you know someone who is and you or they are looking for a job, hire to such an awesome option for the job search because they bring together all these offers from 2,500 different companies in 12 major tech hub cities and you can go through those offers and decide which ones you like and accept or deny them without ever even talking to the company. There's salary and equity and there's full time and contract opportunities. The best part is that it's free and you get a signing bonus if you accept a job of $2,000. But if you use the special code again in the show notes, it will be hired.com slash Developer Tea. If you use that special code, that $2,000 signing bonus goes to $4,000. Go check it out hire.com slash Developer Tea. Thank you again for listening to today's episode and until next time, enjoy your tea.