Today's episode will be focused around codebase also known as a repository. We'll talk about understanding codebase, implementing techniques and deploying. Special thanks to today's sponsor: Hired. Check out hired.com/developertea for free, no obligation job searching and let employers come to you. If you or someone you know is looking for a job in development or design, get on hired.com/developertea.
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!
Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell 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, you can find a summary of it on 12factor.net. 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, DigitalOcean. DigitalOcean, there's a lot of others that will allow you to deploy in this way. In fact, there's even, I'll put this in the show notes, but there's a way of creating kind of your own Heroku on DigitalOcean. It's called Daku and it's through Daku. The idea is to have a kind of a homegrown Heroku docker. And, 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 DigitalOcean. So check that out. 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. It's called web apps or software as a service. And then the site goes on to give a list of the 12-factor apps kind of methodology and why it thinks that it's important to have these 12 factors. I think these are good. And I'm going to go ahead and read you the 12 factors, 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. Number two is the code base. Number three is the code base. Number four is the code base. Number five is the code base. Number six is the code base. Number 11 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 deploys. 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. 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 a commit takes what you have done since you pulled 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 endpoint. And then other things that you can do is you can do things like merge. So 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 what a code base is. And I'm going to talk about something totally different from version control, and that is jobs. If you want to get paid writing clean code and 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. 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 Hired, you can get a job. And 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 Hired.com slash developer T. 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 $1,337 bonus just for helping someone else find a job. And 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 Hired.com slash developer T. Now, speaking of jobs, the really awesome thing about listening to this show and learning about things as 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 job. So, if you're looking for a job, you can 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 Ben Lesh and I. Ben 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're not familiar with 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 with you and you're like, oh, I'm going to have a conversation with this person. And you're like, oh, I'm going to have a conversation with this person. And you're like, oh, I'm going to have a conversation with this person. And you're like, oh, I'm going to have a conversation 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 application's 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 defined 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, and you can create a software that is based on 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 CocoaPods 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, then 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 code that might have been pulled through a package manager. And an example of a package manager would be something like Bower, or perhaps NPM. Another example would be Bundler. And there's operating system-level package management solutions, such as Homebrew or Apt-Get. 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 gem 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. Now, 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. And 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 is the! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! 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. That way you automatically get the show three times a week. Thanks again to today's sponsor, Hired.com. If you are a software engineer or a designer or you know someone who is and you or they are looking for a job, Hired is 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'll 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, Hired.com slash Developer Tea. Thank you again for listening to today's episode. And until next time, enjoy your tea. Thank you.