You can listen to the podcast and read the show notes here.
Michael: Welcome back to the show, I'm here with Nolan Erick and we're going to be looking at Git, and why every ColdFusion developer should be using it, and we'll look at how you can get started and some best practices. So we'll look at what source control is? Because Git is source control and why you shouldn't be using homemade source control. We know the people who make back files and zipped their files and all kinds of other things like that. Am going to explaining why that is a bad idea for security and other issues. Then we're going to have a look at what Git is? And what will different Server client options and some of the commands and some best practices you can use with Git source control for cold fusion? So welcome Nolan.
Nolan: Hi Mike. Thank you for having me.
Michael: And for those of you who don't know Nolan he is the chief ColdFusion guru of [unintelligible, 00:53] productions and he is also the world's biggest music collector in the ColdFusion community, I saw a picture of his album collection, it was like wow! To hear with albums must be thousands of CD's and even [unintelligible, 01:10]. Pretty amazing just in case you were a music collector as well. So why don't we just start off with these three people in the room, or listening to this who don't know what source control is? What is it and why should everyone be using it?
Nolan: So source control is… it's sort of like a librarian for the source code in your app. When you check a book out of the library, the library marks down who has the book? Keep track of who's got each individual you know the book in the library and source control sort of does the same thing for your web app. You might have a few different a few thousand files Making up your web app, and source control keeps track of who changes which change files? What parts have the files changed? When they change them? What the files looks like before each change was added to the system and so on. Source control is like a big library and for the whole codebase. Really the reason everyone… what is your second question? Why should… what's the reason everyone should do it?
Michael: Yeah. Why? Why should everyone listening be using source control?
Nolan: Well, Really for the short answer it is a best practice in the industry right now, not just for ColdFusion code but any source code you write whether it's JavaScript, COBOL, C++ some proprietary scripting language that only ten people in your company either use, whatever the source control whatever the source code is that you're using it should be in source control. Really, if nothing else it acts as another backup for all of the code, so worst case if your laptop gets you know thrown under a bus if your servers crash something like that happens and you need to have a backup of source code.Source code automatically provides you with a backup. if you make some sort of horrendous change to the code, Causing a great big security problem in your app, or causing really bad crash bug things like that, source control makes it really easy to tell what the code looked like before the last change was implemented into the system. It does it all seamlessly all built into the system without any extra overhead or work on the part of the developers, and best of all it does it without anyone making those really annoying [unintelligible, 03:26] and dark old files that we're all… we all have made at some point in our careers that go away entirely as well it’s just kind of reason behind Whatever idea you're using and solves some several problems for you.
Michael: And we'll talk about why it's about idea to make backup copies of files [inaudible, 03:49] Later in the episode, but I just want to point out that you know it's not just the code files, it could be graphics used on your site or it could be the scripts you used in deploying your Docker or your server
Nolan: Yeah it could be used for your docker scripts and your vagrant files and things of that nature too. it doesn't have to be the actual source code that builds your web app if you have other related files that are more for building your application like if you have… if you're a gulp task runner and you've got a gulp script file that has a different gulp watch commands in there you can store that in source control as well, and you can use it to store images on your website. It will certainly do that if you have graphics that could be added and removed from your website as the site is getting used, or as development changes are added to the project. It’ll certainly track those for you as well. it doesn't do quite as good of a job tracking binary files like that like JPEG and PNG as far as changes in the files themselves go, but say you had an instance where maybe I don't know five of the graphics on your website got accidentally erased and replaced with old or lesser quality graphics. If you want to track when that happened maybe whose computer was responsible so you can figure out why that machine is producing worst quality images, then yes source control will help to track down that sort of thing too.
Michael: And some people even put their documentation into source control.
Nolan: Yes. Some people do that too.
Michael: You know I've seen that on open source projects where you know documentation or people even write books in source control.
Nolan: You can… pretty much anything that's a plain text file whether it's HTML or code, or a text file, or a config file, or anything else anything that's plain text it's really really good at monitoring what changes happen to it, and helping you use that as a storing place to show progress in the project and show how things change over time and whatever. So yeah, a lot of people use source control not just for the project, but documentation too and various other related things depending on which Source control tools you are using and which source control provider you're paying for space on, they do give you some other benefits like yeah like giving you basically a free or easy to use space to store documentation describing the website and some other related bells and whistles.
Michael: Cool so really, you use source control on everything, in fact, I wish I could use it on my brain sometimes because I could go back to the state last Tuesday was really productive just…
Nolan: Yes, seriously
Michael: So go back to that all my office so I went back to the way it was really tidy and organized last April you know.
Nolan: I don't think my office ever had a state where it's was really tight in organized
Michael: But if you had to get to your paper maybe it wouldn't
Nolan: Exactly. They need to get for physical papers lying around the office and…
Michael: Yes.
Nolan: Things to get done around the office as well.
Michael: So we mentioned earlier that making backup copies you know what you call it back, or old or put on dating into the extension instead of CFM is a really bad idea, and it's not just because it makes a bunch of clutter in your directories, which if you were someone else is maintaining the app in the future is bound to cause confusion. I mean I've seen that numerous times coming into other people's code and it's like which file do I need to edit? You know which is because sometimes the actual latest version of the file is not the one you think, But one of the other issues with making back, or old, or copying into new directories.
Nolan: Well, it does do all the things you mention words clutter the website, and It's hard to tell which file is the most recent which file has?… Which changed you know how to tell which file was the most recent backup and which backup came immediately before that and so on. The other medium-sized concern with that file is, it's hard to tell what's different between them if I have my doc. CFM file and let's say index doc CFM just for an example and I am making an index doc old with some changes in it that are not in the dot CFM version that I'm making an index doc back, or index doc back up, when I have an index doc old, index doc back up, and index doc CFM. There’s no easy way to tell by looking at those which changes are in the doc back version, which changes are in doc old version. Why I made the change from one to the other and so on? The bigger issue though too is if you leave those files lying around with the nonstandard extensions doc back; doc old, doc mines whatever you come up with, the server side source code is still in those files. If they… and this is true whether its cold fusion, or PHP, or doc net, or Ruby or any other server-side programming language out there. If you change the file so it has a different extension on it than what your web server expects, so in the case of cold fusion change from doc CFM to dot back. A hacker can then go to the URL in their browser and they'll just type in you know site name dot com slash index doc CFM, they can change that doc CFM part to doc old, or doc mine, or doc one whatever the common things are the developers typically use to rename their backup files, since that file does not have the correct extension on it the cold fusion server is not going to process that file, instead of it being run through cold fusion and only of the HTML and javascript showing up in the browser, what happens is all of the server side cold fusion code shows up in the browser instead, and the hacker now has a really easy way to see actual server side running code from that web app. sometimes it might be nothing, but sometimes people have usernames and passwords in their source code files, or at the very least it probably has a horrible idea by itself don't ever do that, but separate from that You'll have things like database queries in there, and people who… hacker can see the names of tables in your database it might be a little, but some of the columns are in your database how certain tables relate to each other maybe other pieces of information about how the infrastructure of your Web site is set up. Basically a lot of free information can be given to hackers, so they can try to bust into your website all, because you have a file on the server with the wrong extension on the doc back, or doc mine, or whatever. So just by making those old backup files, if they accidentally in that one your production web server, boom! You now open yourself up to a pretty bad security hole.
Michael: That is amazing and I bet a lot of people listening hadn't realized that. What about if you know working with a team just using making copies of the file, make that harder if you need to share files and edit with a lot of people.
Nolan: Yeah exactly, like without source control let's say you and I Michael are working on a project together and I change the application CFC and I add some new features to it if we are not using source control, I have to e-mail that file to you. One file itself, not a terribly difficult process you could download the file and drop it in your project no big deal. What happens though if I make a change to applications CFC and unknown to me you also made a change to application CFC well, now who's file is the point of truth did make the correct change? Or did you make the correct change? And when I email you a copy of one file are you going to know that you are changing the same file I changed a minute ago? Are you going to know about Dev? your copy with my copy make sure that all the changes are in there maybe; maybe not sometimes we'll just forget you could do those things and not just with one file What if I changed but if I added a new feature to the app? And I had to touch twenty files to make that change happen. Those twenty files might be in four or five different directories in the app now you've got a whole lot of manual work to do to copy and paste the files in different places in the app, and it gets very tedious very quickly.
Michael: And error prone.
Nolan: Yeah very error prone, not a great way for anyone to spend their time, multiply that out by what if we have a team of seven developers. I make a change is able to change out to the six other people on the team, now all six of them have to do this really tedious dropping file into different places six more people making the changes that six more chunks of man hours that we're now paying for that's just wasted logistics. Six more possibilities for error-prone things to happen as well so it's not a good use of anyone's time, instead you can use source control and just say tell us what the source control system I'm making a new feature to the app called Whatever your feature is called I'm making the save user button you know work, and then I just checked that feature into source control literally, with the click of a button all six other people on the team can download that change all the files automatically go to the right spot, there are no doc back, or doc old files that are created. nobody has to manually copy things from folder to folder it just works, and best of all to if I have to break something during that change, those files are noted as these are the ones that Nolan changed, these of the lines that he changed you can get an easy snapshot of what the code looked like before and after I messed with something makes it really really easy to tell, Oh! Nolan made the change in a such and such file in the app, he accidentally forgot to [inaudible, 13:14] of the line and something broke, or whatever the case maybe tracks all of that stuff for you really easily.
Michael: And we'll talk a bit about what you're talking about is merging changes and we'll talk more in detail later, but I just want to point out the other developers can choose whether they're going to take your changes now, or tomorrow, or whenever it's convenient for them based on what they're changing, because maybe they're not ready to merge in your changes because they haven't been QA, or maybe they want to now because they know you just fix something that important for what they are working on, so it leaves you a choice, because I'm thinking some people might be thinking that hey we can all just work straight on the production server right? Wouldn’t that always lead to a problem?
Nolan: No that does not [inaudible, 14:01]
Michael: Why wouldn't that be a solution right
Nolan: Oh man why [unintelligible, 14:06] on a production server so many many reasons not to work directly on the production server.
Michael: I don't even know where to begin with, there are so many possibilities here it's just it's the production…
Nolan: If you're in a development environment if I write code on my laptop I am the only user on the laptop, but let say am working on my laptop and the code I'm working on is Delete user functionality and there's a giant bug in the delete user functionality that lets the code be run by Anyone who comes across it they don't have to log in with admin rights first they can just find the link and click it. If I'm working on my laptop I know that I'm the only person using my laptop, there's no way someone else could accidentally run that code. I have my own separate local copy of the app in the database and everything like that, and I can test everything to locally if I'm writing code on the production server directly, there's a possibility that someone else is going to click that link at the same time even if you think oh my site doesn't get that much traffic. I only launched my side a couple of days ago Google hasn't found it yet nothing is crawling that Web site looking for links yet, I'm fine. Google crossings a lot faster than we think they do and if you don't have your website secure in lockdown It could very well be trying to trace through all the links and clicking on them and accidentally trigger code you don't want to run. so it's always a good idea just to not change anything in production change it on your local environment first In fact what other people like to do sometimes is not necessarily change well in production, but they'll have sort of a shared development server where maybe the team of eight developers all writes code on the same Development cold fusion server, and even that can be a troublesome situation if you want to avoid… Might have… if I make a break in the app that down the entire system, so it's not usable if it's just my laptop fine; I can't write code until I fix the problem if we're using a shared database, or a shared dev server then all seven or eight other people on the team can't write code either until I fix it. so really, it's better just to keep everything compartmentalize and away from the production server as much as possible, and they're really good tools these days it makes it super easy to check your production server and only push changes up to it when they're ready to go anyway.
Michael: I think that makes a lot of sense and just to point out to people even a shared dev server doesn't solve the problem of someone else, so writing your changes [inaudible, 16:29] both at the same files at the same time.
Nolan: Exactly and I've seen that happen before at places too that you're not using source control the only way to solve that problem is using source control or version control system. They mean the same thing it's just hear people use one term or the other.
Michael: All right well, I and millions of other people [inaudible, 16:45] we should be using source control why should we use Git as our source control system?
Nolan: The short answer is it just kind of becoming the industry standard tool right now, there are several different options out there you could use Git, you could use subversion. Microsoft has one called Team foundation server there are less than I guess about a handful of other possibilities out there if you want to go through something else as well. The nice thing about Git is, it's free you don't have to actually pay anyone to download a Git client. It works on Windows, Mac, and Linux. There are a variety of tools available for it, so if you're more of a command line person and you like writing command line scripts like node commands and things like that, you can write Git commands in a very similar fashion to manage marking all of your files checking them in and out of source control and so on. And if you're like me and you can't stand doing source control from a command line you prefer to have some sort of gooey tool books or like your operating system, the use of folders and files within those folders, there are various great tools out there that implement Git source control using that set up as well. the one I personally like a lot is called source tree it's made by [unintelligible, 17:59] The nice thing about source tree is, it's free all you have to do is make Atlassian account and it works on windows Mac and Linux as well so you can use it for whatever platform you like and shameless plug when I get my talk next week see if camp in