You can listen to the podcast and read the show notes here
Michaela Light: Welcome back to the show. I am Michaela Light from TeraTech, and I'm here with George Murphy, long time ColdFusion developer. He is an expert on GitLab, and he's giving a talk at Into The Box all about GitLab and some of its amazing features, including Continuous Integration. We're going to be talking about not just GitLab, but some other repositories you can use for source control.
We'll also check in what the hell is source control, and why everyone who does ColdFusion should be using it. In our recent State of the Union survey, not everyone is using source control. We'll also look at what Continuous Integration is and why you should be using that, and how GitLab lets you do that for free, and some of the other features in there.
Welcome George.
George Murphy: Thank you Michael.
Michaela Light: Let's start off with, what the heck is source control? I know every listener here probably knows what it is, but just in case anyone didn't. Why is it critical to use it on every single ColdFusion project you do?
George Murphy: To keep it real simple, source control is a way for developers to be able to commit their code and to be able to keep different versions of their code without having a bunch of folders and forgetting what folder you saved something in, or having your laptop or your work station hard drive crap out on you, and you have no way of going back to recover your code. That's what version control is.
The beautiful thing about version control, it allows you to go back in time to a certain commit, and to be able to recover that entire repository exactly as it was when you committed it. You can go back, you can take a look, and then you can go forward from there, back to where you were.
Michaela Light: If you were coding on a project, and heaven forbid, a bug appeared, you could see all the lines of code that have been changed by you or other teammates, and then that might help you figure out what was going on with it.
George Murphy: Absolutely. We've had situations on projects where a bug has been introduced, and we've had to go back to another commit, and go with that, and then we'll take it and we'll create another branch. A branch is sort of like another highway of your code, so you're able to continue on without that bug, but over on the other branch, you're trying to figure out, how did this happen? Once you get it fixed, you can merge it back into your code, which is very, very useful.
Michaela Light: If you were on a team and you were working on one set of bugs, and some other people working on a different set, but you needed to edit the same files, you guys could both do that. You could merge the changes back together once you tested them out, or even, when you say a different branch that's like a different version of the software, you could have two different versions, but maintain both of them.
George Murphy: Yeah, absolutely. What we do is, we have several versions of our site running, and we'll have different branches be deployed to different servers, so that we've got a stable branch, we've got a development branch, which we always do Continuous Integration to. We never merge it into our stable branch until we verify that it's ready to go. We're able to do that and to keep working.
If you came to me and said, “Hey, George, I need a feature that's going to allow me to do a survey.” I would create a feature branch called Survey, and then I would do all my work there. Once you looked at it and verified it, then I could merge it into my stable branch, and then do whatever else I needed to do to get it to production. The way we get things to production is through Continuous Integration.
Michaela Light: We'll talk about Continuous Integration, explain what that is a bit later. While you are working on that branch for that different feature, all the other developers don't have to be affected by all the changes you're making. They have their own branches.
George Murphy: Absolutely not. They can work on their own branches without interfering with anything that I'm doing.
Michaela Light: I know your code is totally bug free 100% of the time, but in case someone-
George Murphy: Oh, I wish it were that way, but unfortunately it's not.
Michaela Light: This avoids when you're adding a new feature, some things might not work for 10 minutes or an hour, but that doesn't screw up other people because they've got their own branch or copy of the code.
George Murphy: Yes, that's very true. It gives you a lot of flexibility because you can turn on a dime. That's very important nowadays because people want to get their code out quickly, and they want to be able to change it without waiting for weeks or days to get it pushed out. If you take this approach, this is something that's going to allow you to deliver your code much quicker, and have a safety net there for you, in case if something bad does happen, you can easily recover from it.
Michaela Light: Okay. I hope everyone listening is now convinced that having source control is a good idea. Many different software we can use for doing source control. You're using Git, why do you like Git over Subversion or other source control systems?
George Murphy: The reason I like Git is because Git is different from Subversion and CVS in the sense that, if you needed to create a branch in Subversion, you are copying that entire file system, whereas in Git, it's just the pointer to the change.
You're not creating another whole repository the way you are in Subversion and CVS, you are merely writing those changes to a database and Git keeps track of what the change was, and it gives it a hashtag that's a GUID, which is a really long, long character string, and it's garbled.
It's given you a GUID, so if you ever want to get back to that particular state in time, it's as simple as writing ‘git checkout', and then the hashtag of that commit that you made, and you're right back where you were. That is beautiful.
I've worked on Subversion projects before that were really big projects, and we were having disc problems because we were running out of space because we had all these branches. Every time we do that, we're copying the entire file system.
Michaela Light: The other thing I've seen with Git is, it makes merging much easier than it is in other source control systems. Have you found that too?
George Murphy: Absolutely. If we were on a development branch and we had a branch called Feature George, it's as simple as writing ‘git merge feature george'. Feature George is merged into the development branch, it's as simple as that.
The other thing that we're doing is using what's called tags. Git tags. These tags allow us to be able to freeze our code at a certain point in time. Everything that we move to production, we tag it, and then that way, if we put something up there that's not working right or we make a mistake, we can very easily revert back to another tag. That code is frozen, you don't write to that code, you don't make any changes to those tags, so it's like a snapshot in history.
Michaela Light: The other thing I like about Git is, it's really designed for distributed use, unlike some of these other source control tools, where to use it, you need to be right there in the building. With Git, you could be anywhere in the world, and that's where it started, right? With the open source movement and people needing to share code repositories.
George Murphy: Yeah, it started from the guy who invented the Linux operating system. That was such a huge project, and he wanted to have other people be able to work on the code and not be locked down where you had to login to commit your code. If your code blew up, you had no way of recovering it. The thing I love about Git is, let's say your Git server went down, just blew up the disc-
Michaela Light: Your Git server went down?
George Murphy: Let's say your Git server went down, your Git repository server.
Michaela Light: Right.
George Murphy: The remote server, I'm talking about, not the local. The way Git works, every machine has its own repository. On your laptop, if you were writing some code on your laptop, it's got its own Git repository.
When you're done, you commit that code to a remote server, but let's say that remote server went down. We stand up another server, we take your local copy, we push it to the remote serve, and voila. We've lost very little.
Michaela Light: It's resilient.
George Murphy: It very resilient. In fact, I remember something happened once where I no longer had access to a server because something had happened. I forget exactly what it was, but we were able to recover from a local copy, and to put it back up there, and be working in a matter of no time.
In fact, I remember, one of my GitLab VMs took a power hit, and I immediately said, “Okay, I'm going to take my local copy and move it to DigitalOcean,” and I was back up and running in no time.
Michaela Light: Wow. Let's move on. We've looked at why you should do source control, why you should pick Git for your repository for source control. Why GitLab, as opposed to Bitbucket or GitHub or any of the other flavors of Git you can get?
George Murphy: The reason you should look at GitLab as your repository of choice is because GitLab gives you the option of, number one, it's free, and then people say to me, “Well, GitHub is free.” Yeah it is free, but if you want private repositories, you're limited on the number of users that you can have contributing to those different repositories.
Michaela Light: Do you know what the limit is? Is it five or …?
George Murphy: I know on Bitbucket it's 10 users. I'm not sure about GitHub, but you're limited in terms of the number of users that you can have contributing to your project. If you're doing any type of development, you run out of the ability to add people, then you have to drop people, and add people, and drop them, and add them. It's not a way to work. If you use GitLab Community Edition, which is the free version of GitLab, you don't have to worry about that.
Michaela Light: Unlimited.
George Murphy: Yes, you have unlimited. The only limitation is your hardware.
Michaela Light: Okay.
George Murphy: If you have a very beefy machine, you can do whatever you want.
Michaela Light: You mentioned private repository versus public. Why is that important?
George Murphy: That is important because as you develop, and you have clients, clients don't want their code sitting out for all prying eyes to see. It could be a sensitive project, it could be something that client does not want sitting out in the public space. If you're using GitLab, you don't need worry about that.
In fact, it's on the approved list, and for those of you that don't know what that is, that's a list that the government keeps for the DoD space, and they have a list of the different approved software and so forth. GitLab Enterprise is an approved version controls system.
If you're working with other clients who are not government based or so forth, you still don't always want to keep your code out in the public sphere. GitLab Community Edition is a great way to have your repositories private. With all the hackers and things out there today, it's not a good idea to keep your code in the public space, unless it's open source stuff.
Michaela Light: I was going to ask you, why would anyone want to use a public repository? The answer is, if you're working on an open source project, you'd want it to be public.
George Murphy: Absolutely. The other thing that I have done with GitLab is, I've set up mirroring. I have a GitHub account as well, but I do all of my development to my GitLab server and then I mirror it to GitHub if it's open source stuff. That way I've got it in two places, and it's just a comfort factor.
Michaela Light: All right, we've got GitLab, but what are the options for what you run that on?
George Murphy: GitLab needs to run on an Elixir, and there are a couple of different ways you can get that server. Bitnami has fully configured GitLab servers, OS's that come in as OVF files, which can run in VirtualBox or in VMware Player, or in VMware Workstation. They can also run in the DigitalOcean domain, Amazon, Windows Azure. They can run anywhere.
You can actually build your own server from scratch if you want, where you would take an Ubuntu server and you would install GitLab on it, or you could take CentOS or Red Hat or Debian, any of those Linux based systems, and install GitLab on it. I've learned how to do that.
At the Into The Box, we're going to be looking at a GitLab server that I put together, and for those of you that make it to end of the box, I'll have a free server to give out to you, already configured and everything, along with the instructions on how to get it up and running.
Michaela Light: Wow. If someone was curious about this and they came to your talk, they could have this up in minutes and be playing with it.
George Murphy: Yes, absolutely. In fact, one of the things that I plan on doing in the presentation is to be able to have another developer work on a project with me. He commits the code back to my local repository running on my laptop, and then I'm going to push that code straight to Hostech. You're going to be able to see how it all comes together and how it works.
Michaela Light: Fabulous. You're using GitLab for source control, but it does a whole bunch of other things. What are the other great features you like in GitLab?
George Murphy: I'm glad that you asked that, it's a great question Michael. One of the really, really nice features of GitLab is, it's got an issue tracker in there, or bug tracker. They call it an issue tracker, but it's for documenting bugs and assigning them to other team members. They get notified through email or through Slack.
GitLab also integrates wonderfully with about 25 or 30 other products. One of those products that we're using right now is Slack, which is tool for work, which allows you to create channels. In those channels, they can be private or public to the team. You can get notifications about different things, you can have one on one meetings with as many people as are in that project.
If an issue is created in GitLab, you can have those issues sent to the channel, and if it's assigned to you Michael, you can set up your computer, where you'll have a special little ding or chime, so that you know, “Hey, that's for me.” The stuff that's not for you, you can turn that off, so you're not constantly going there.
We're averaging about 300 messages a week on this project that I'm working on now, and if you don't turn those notifications off, it can get annoying, but I've done that. The other cool part about GitLab, let's say you're not happy with the issue tracker that's in there, you can integrate JIRA if you would like, you can integrate Bugzilla you can use in there.
It's really a nice product, and it also has a built in wiki. Each repository can have its own wiki, so you can have built in notification with the mark up. The other thing I like about the GitLab team is they're very responsive to new ideas and new things that you may want to do.
It may be something's missing out of the product, if you put in a feature request, they respond to it right away. They'll tell you, “Yeah, we can do that. This is in the roadmap in this version.”
I'll give you an example. I wanted to be able to know who had assigned the issue in GitLab, so I could see it in Slack. Before, you would see it, and you would see it was assigned to you, but you didn't know who assigned it. I put a feature request in there, and within two weeks' time, they had integrated that feature into the community edition, and it was really, really nice.
Another product that's also a big part of GitLab is Kyber, which is a part of Slack, but because you can integrate Slack into GitLab, you can use these other tools that are integrated with Slack. What Kyber allows you to do is to create meeting requests, to-do requests, reminders, and a whole slew of things. It's great for a development team, even from one developer projects to as many as 100 developers.
Michaela Light: Wow.
George Murphy: Yeah. It's an awesome, awesome product.
Michaela Light: You mentioned you use GitLab's Continuous Integration feature. For people who aren't doing Continuous Integration, what is that, and why should they be doing it?
George Murphy: Continuous Integration is the ability to publish your code, review it, and push it right to production. The reason you should be doing that is because many developers are not using version control. They're doing more or less what's called a waterfall technique, where you and I work on something for weeks and weeks and weeks, we push it, and we find out, “Oh, I've overwritten some of your code, you've overwritten some of my mine.” There's all types of problems, and then the client hasn't seen this for weeks and weeks, and they look at it and they say, “That's not what I wanted.”
If you're doing Continuous Integration, you can have nightly commits or hourly commits. However quickly you can produce this code, you can commit it to a server, so that you can get immediate feedback on it. That is the beauty of Continuous Integration.
Michaela Light: Continuous Integration is the process where daily you have a fresh build, it's up on the staging server or whatever server you were trying things out on. The idea is you have some software that automates that, so you're not manually copying which files have changed around and all the other fun things you do when you copy code over to the server.
George Murphy: Right. The old way we would do it is, we would either have a shared drive or SFTP or FTP. You would have to make a list of what files you had changed, or you would have to look at the modified date and hope that you had committed everything that you had done. I can't tell you how many times where that has let me down.
If you're doing Continuous Integration, you're not going to need to worry about that because when you commit your code, it's going to give you a list of what changes were made. You can accept those, you can stash those, which means you don't commit them, and the stuff you want to commit, you put it up there.
Soon as you commit it, and it goes into the GitLab server, GitLab will talk to your other server and move that code there for you, so you don't have to worry about have I moved everything. Then it's going to give you a list so you can back in time and see what files moved there, who moved them, what time they moved them. You can see all of that.
That's a great way of working, and it allows you to be able to have some comfort and not be sitting there with knots in your stomach wondering, did I get this right?
Michaela Light: Right. If you have automated testing written, whether it's TestBox or MXUnit or any of your other automated testing tools, that Continuous Integration could be kicking off automated tests to make sure that the software doesn't have any silly bugs in it, without you having to manually test it.
George Murphy: Yes, absolutely, it works like Jenkins. It doesn't have all the bells and whistles that Jenkins has, but it will run tests for you, and it will give you notifications if those tests fail. If the tests do fail, it will not commit the code, but it will send notification to the whole team that the test failed. You fix your code and recommit it, the tests pass then it gets committed, it gets moved to the development server, so that we keep that Continuous Integration going.
In fact, the way we use it in terms of Continuous Integration, we don't have it automatically push into production because we want to look at it in development first, move it to staging, verify that it's working there, and then we open up a browser. We log into the GitLab server, and we click one button that says push to production. It opens up a connection to that server, it pushes the files there.
When it's done, it gives me a report of what files were moved, so that I know exactly what was moved. If I need to go back in history to check on that, I can do that, and it's all there for you in the UI.
Michaela Light: Heaven forbid you needed to roll back to a prior version on the production server, you could do that with a few clicks and you'd be deployed.
George Murphy: Absolutely. What you can do, you've got a couple of different ways you can do it. You can ask it to remove files for you, or you can say, “Okay, go to this build and push the files out for this build,” and it will do all of that for you.
Michaela Light: Wow. I'm excited about your talk at Into The Box. I want to change gears for a moment, and ask some other questions, if that's okay.
George Murphy: Yeah, that's fine.
Michaela Light: Why are you proud to develop in ColdFusion George?
George Murphy: I proud to develop in ColdFusion because ColdFusion has been a very, very exciting product for me. I've watched the product grow and mature, and it's keeping up with all the latest technologies. Developing this product has been very, very good for me, it's been able to feed my family and to take care of those personal things, and it's a fun product to develop with.
Michaela Light: It lets you do things fast too.
George Murphy: Yes. That's the most important thing because many clients, they don't have the time to go into these huge waterfall projects where it takes months and years to kick it out the door. They may have a couple of months at best, and ColdFusion allows me to deliver on that.
Michaela Light: I know you do a lot of projects in the government sector. Is ColdFusion popular there?
George Murphy: Yes, it still is, despite what you may have heard. ColdFusion is still alive and well in the government, and new projects are being produced in it all the time. With a lot of the new ColdBox products that are coming out, they're really adopting this product, and I'm very happy about that. The thing that makes it different from a lot of the other products out there is the turnaround time. It can be turned around very rapidly.
Michaela Light: What would it take to make ColdFusion even more alive this year?
George Murphy: One of the things that I would like to see on a personal note is, I would like to see us be able to integrate more of the different Java products into ColdFusion because ColdFusion is running on top of Java. For example, I'm working on a project right now, where we want to integrate a Hibernate inverse, which is an auditing system that's part of the Hibernate package.
That's not part of the ColdFusion core, so you have to do a lot of work to bring that in and get it on the class path, and get it up and running. It would be nice if that were a part of it. It would allow us to have auditing rite out of the box, which is a requirement for any public project that you're doing nowadays. Any government project, you have to have auditing, and if this were built in, it would be a great thing.
Michaela Light: All right. What are you looking forward to at the Into The Box conference?
George Murphy: I'm looking forward to seeing my fellow ColdBox developers, learning some new things. I want to really get grounded in TestBox, I'm going to take a TestBox class while I'm out there. I plan on also looking further into REST and REST development. I also want to look at UJS, which is JavaScript library that ColdBox team is starting to use extensively across a lot of their products now
There's a new product called ColdBox Elixir, which is a way for you to manage Gulp and manage Sass, so that when you make changes to your JavaScript, it doesn't cache it for you, and it allows you to see your changes immediately. It re-minifys it and pushes that code out. It's sort of the Continuous Integration of JavaScript and CSS, but it's done locally, as opposed to the server.
When you get ready to deploy your product, it minifys everything and packages all those assets for you, so that you don't have to worry about the missing assets. Are we going to have all the dependencies and so forth and so on? One other thing I wanted to mention too is, if you don't know about CommandBox and you're a ColdFusion developer, you need to investigate this because CommandBox has changed the way I develop.
What it does is, it allows you to have a ColdFusion server running locally on your machine without the full install of ColdFusion, which can be a resource hog. If you're using CommandBox, you don't need to worry about that.
The other wonderful thing about CommandBox is, I can install LUCY 4/5, LUCY 5, ColdFusion 9/2, ColdFusion 10, ColdFusion 11, ColdFusion 2016, and have all those servers running as a WAR file. If I have a beefy enough machine, I've ran two and three servers at the same time, had them all talking to each other.
Michaela Light: Wow.
George Murphy: It's a very cool thing.
Michaela Light: CommandBox is a free open source project, so no reason not to check it out.
George Murphy: Yes. It's free, it's open source, and if you haven't checked it out, check it out. The wonderful thing about it is, it'll run any ColdFusion, so if you've got some old legacy code that you want to modernize, CommandBox is a great way of doing that.
Michaela Light: Fabulous. For folks who haven't heard of Into The Box, or maybe they heard of it a few years ago when it was a one day event. This is now, I think, three days, including the workshop day. It's not just Box products, it's a whole bunch of ColdFusion best practices talks like the one you're doing.
George Murphy: Absolutely. It's not just Box products, it's a development methodology in terms of how you can do your developing, so it doesn't matter if you're not using the framework, there will be something there for everybody. The most wonderful thing about it is, you can bounce ideas off of each other and get some feedback for it.
The thing I love about all conferences is the fact that when I go to them, I always bring something back very valuable. I have ran into prospective clients, I've gotten business from these conferences. It's been a really good thing.
Michaela Light: What would you say to someone that says it's a really long way to travel to Houston, Texas?
George Murphy: I would say, “Don't worry about that, just get on the car, the plane, the train, the bus. Whatever you need to do, come on down.” If you're in the north east, you definitely need to go, you had all that snow up there. You'll have a great time, you'll improve your lot as a developer. You can not walk away from these conferences and not enrich yourself.
Michaela Light: Great. I hope your talk goes wonderfully George.
George Murphy: Thank you Michael.
Michaela Light: Thank you for being on the show today.
George Murphy: It was my pleasure.
