026 Gitlab Server Deep Dive with Continuous Integration, with George Murphy

 

George Murphy talks about “Gitlab Server Deep Dive with Continuous Integration” in this episode of ColdFusion Alive podcast with host Michaela Light.

John was one of the speakers at the Into The Box ColdFusion Conference, where he talked about Gitlab server with Continuous Integration.

Are you ready to do a deep dive into setting up a Gitlab Repository on your localhost and doing Continuous Integration with your team?

Episode highlights

• Why Source Control is critical on every ColdFusion project
• Why a Git repository? (over subversion or CVS etc)
  • Only save deltas of code changes, not copy whole repository
  • Easier merging
  • Git tags for code freezing, version releases
  • Built for distributed team
  • Immediate code sharing
• Concern over public vs private code repository
• Why Gitlab?
  • Enterprise edition paid per user
  • Community edition free
  • You can run GitLab:
    • on site on a Linux server
    • VM
      • Virtual box
      • VM player or workstation
    • Cloud
  • Built in issue tracker
  • Built in Continuous Integration
  • Built in wiki for documentation
  • 25+ 3rd party integrations including:
    • Slack integration to notify commits made by team members in a certain slack channel
  • Integration with JIRA, Bugzilla
• Alternative Git services:
  • Github
  • Bitbucket
• What is Continuous Integration and why you should be using it?
• Why are you proud to develop in CF?
  • RAD of very complex apps
  • Govt use CF a lot
• WWIT to make CF even more alive this year?

Mentioned in this episode

• Bit N OBF files Virtual Box
• Digital Ocean droplets
• ESXI virtual machine
• No need for FTP or SSH
• GitLab CI tools – no need for Jenkins
• Slack 3rd party tools eg Kyber online meetings from Slack
• Jenkins Continuous Integration
• CommandBox

And to continue learning how to make your ColdFusion apps more modern and alive, I encourage you to download our free ColdFusion Alive Best Practices Checklist.

Because… perhaps you are responsible for a mission-critical or revenue-generating CF application that you don’t trust 100%, where implementing new features is a painful ad-hoc process with slow turnaround even for simple requests.

What if you have no contingency plan for a sudden developer departure or a server outage? Perhaps every time a new freelancer works on your site, something breaks. Or your application availability, security, and reliability are poor.

And if you are depending on ColdFusion for your job, then you can’t afford to let your CF development methods die on the vine.

You’re making a high-stakes bet that everything is going to be OK using the same old app creation ways in that one language — forever.

All it would take is for your fellow CF developer to quit or for your CIO to decide to leave the (falsely) perceived sinking ship of CFML and you could lose everything—your project, your hard-won CF skills, and possibly even your job.

Luckily, there are a number of simple, logical steps you can take now to protect yourself from these obvious risks.

No Brainer ColdFusion Best Practices to Ensure You Thrive No Matter What Happens Next

ColdFusion Alive Best Practices Checklist

Modern ColdFusion development best practices that reduce stress, inefficiency, project lifecycle costs while simultaneously increasing project velocity and innovation.

√ Easily create a consistent server architecture across development, testing, and production

√ A modern test environment to prevent bugs from spreading

√ Automated continuous integration tools that work well with CF

√ A portable development environment baked into your codebase… for free!

 

Learn about these and many more strategies in our free ColdFusion Alive Best Practices Checklist.

Bio

George is a long time CF developer, focused on ColdBox and CF server maintenance. Currently Senior Software Developer at Fig Leaf Software. He's been working with and exploring various web technologies since the late nineties. ColdFusion aficionado since version 4.5. ColdBox Evangelist. Loves collaborating with other developers and bouncing ideas off them and having them bounce ideas off me. I truly love spending and sharing my time with my lovely wife, daughter and friends.

Links

• Twitter
• Website

(* WWIT = What Would It Take)

Interview transcript

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.

Read more