Git-Based Workflows

SPEAKER:
So, yeah, I proposed this session when it didn't seem like there was anything similar going on. I didn't have anything particular in mind that I wanted to go over, but I figured we could make it a discussion. And, yeah, anyone who has experience with any particular systems can maybe talk about their experience. I think the best way to get started would be just to maybe go around and talk about what your experiences are with Git-Based Workflows. Benji, you're in my top left there. You wanna start?

BENJI:
Hi? So, I've been using Git as long as I've been working with Drupal, which is coming on in 10 years or so now. I don't know why we don't follow any strict Git flow process, but we do have... Where I currently work, we have a main branch where merge requests get merged. And then when it's ready to deploy, we push to a staging branch and a (INAUDIBLE) branch and those trigger deployments. So, feature branches off of main (INAUDIBLE).

SPEAKER:
And what... Where are those deploying to as far as the environment?

BENJI:
So, this is the first company I've worked at where we actually do our own hosting. So, we have (INAUDIBLE) We're very fancy. We have a self hosted GitLab, which is where the branches live. So, every push to quit GitLab triggers all of these continuous integration jobs that those docker containers and all sorts of funny stuff and then pushes to the staging and release branches, well, (INAUDIBLE) trigger deployments.

SPEAKER:
Cool. How about you, Jack?

JACK FRANKS:
Well, we have a Git flow ask sort of a workflow, you know, a development workflow. We don't strictly follow Git flow, but, you know, tickets have their own feature branch, you know, that fixes and whatever. We'll get their own working branches as well. It's mostly private GitHub repos, but we do have some privately use to Git lab as well. But my three or four projects right now happen on the GitHub. I don't have any hooks or automatic testing set up for when things get pushed or (INAUDIBLE) , which is something that I would really love to learn how to do. And where hosted, actually, all the apps that I'm working on are AWS hosted. So, we have a CD process for that. The developer set up using AWS code pipeline. They're manually triggered now for Pride and QA but the Dev environment does get automatically pushed every time. So, we have to be a little more cognizant, you know, this is our first couple of projects that aren't manually deployed. So, if we wanna do something like, OK, we'll roll back this (INAUDIBLE) and update it so that some of this, you know, real important content gets, you know, gets updated in the new build, you know, something like that, they have to be update us to do this and whatever.

There's no more just SSH getting into the server, doing the poll, doing the, you know, doing a special step or a deployment, whatever. There is a script that runs. So, we have to exist within that framework now. But mostly what I wanna learn about are hooks and, you know, automatically instantiating containers and getting tests run when, you know, when stuff gets pushed.

SPEAKER:
Oh yeah. And I think that's part of what I want. Everybody has a chance here. I'll show what I've been doing on a recent project and (INAUDIBLE) that's going on. Adrian, you mentioned you guys are using Pantheon. Anything else you worked with or are interested in knowing more about?

ADRIAN MCKEE:
Well, (INAUDIBLE) we're doing? We're taking over a couple of sites now that are self hosted using cPanel. And so we're trying to work out a thing on GitLab to do CI/CD and then push to cPanel for our site as well. And so I'm learning as you go with docker and Lando and all that stuff as well, as well as it get. I have my own environment where I got a couple of servers set up. One I use for testing Dev, and the other one is my life server black sites. And that's basically just GitHub. Nothing fancy yet for that.

SPEAKER:
Alright, how about you, Mauricio?

MAURICIO DINARTE:
Everyone, this's Mauricio Dinarte, (INAUDIBLE). I have been working with Git baseball pros for (INAUDIBLE) about a decades, but most of the time all them, you know, just working with Git itself. I have never had the chance to set up, like deployment workflows, CI/CD or anything like that. Most of the time I am part of a bigger group and someone else takes care of doing that. So, I have learned a little bit here and there over the years. But I would like to just like dig deeper into how to do that, work the options. Yea, that's it.

SPEAKER:
Alright. We can definitely get into some of that, uh, Brian.

BRIAN:
Hi, I'm Brian. I work at Reaching Across Illinois Library System. Mostly we're working with our vendors and I do what they tell me to do as far as getting everything from, you know, from the repo deployed on to both our tests server and production. We sell post, but, you know, we have vendors who support us and, you know, using one vendor currently platform that S.H. for the repo and then also GitHub.

SPEAKER:
Alright. Karen, you jumped on a few minutes late. Yeah, we're just gonna talk about our experiences here. We, know know, no particular structure planned for this session, but I figured once we can all talk and kind of try to give it some direction. So, yeah, any experience you have with this kind of stuff or to learn more about?

KAREN:
Well, I am a front-Ender and I do a lot with sites that are on Pantheon and Platform.sh. So, for me it's just get pushing to the correct branch either on a multi Dev but the dev... So, the CI/CD stuff is all built in with platform.sh and Pantheon. So, I don't have to deal with that. But yeah. Now Git, it's just, I got my fingers, it just automatic Git commands. I got all my little shortcut aliases in my shell and so that's really just a new branch with the feature I'm working on, merge it into the multi Dev branch, push it up to Pantheon and let Pantheon take the rest of it. So, that's about it for me, but, yeah, I mean, it's amazing what we can do with GitHub and GitLab and I want those now.

SPEAKER:
Yeah. Definitely. Yeah. Alright. So, I think maybe I'll kind of show it. See if I share my screen. I don't have any slides or anything like that, but I will maybe pull up some code here that we can look at. We will talk about services first. So, GitHub, GitLab, Bitbucket, they all seem to have some sort of CI/CD stuff built in nowadays, which is kind of nice if you wanna simplify and use fewer features, oh I'm sorry, fewer services. The ability to spin up like an instance of your site, run commands against it, it's pretty nice. I use GitHub on my current project that I've been doing a lot of the stuff with. And the way our workflow works is, we, like I said, we use GitHub. I have some... I use Lando locally. And I have an entire environment built out there and we have some automated testing stuff set up there in Lando and we actually have GitHub actions set up, which is the CI/CD system where you define an environment. It will run some scripts in that environment. So, what we've done is they've actually told GitHub, OK, is spin up an instance of a server, install Lando, pull in the, you know, check out the latest version of the code, whichever branch, if you make a pull request it automatically triggers this for that branch that pull request is for.

Pull request, if you're not particularly familiar with GitHub is, you know, basically you wanna merge in your code and it sets up like a separate area to discuss and review the changes. And now with the actions, you have to perform actions on that. Like I said, we install Lando, we pull in that environment with those changes and actually run Lando, run our environment and run the tests that were configured to work in Lando in our environment. Lando being a local development system, in case you're not familiar, it's data based system, but it allows you to specifically define your environment locally and therefore we can say, OK, we've got this environment, we already know it works well locally and it's already meant to look a lot like our production system. We don't need to define yet another environment in the GitHub site. We can just use the one we've already defined or the one we know that works. So, that works out pretty well, runs the script, runs the tests automatically. You just basically have to, if your script returns an error code, GitHub will mark that as a failure of that action, which actually you can set up in GitHub to prevent merging of that pull request.

So, if you have a test failure triggered that way or any, you know, there's many ways you could go about it, but it'll, you know, say, OK, test failed, don't merge this and you can actually block that. So, that's kind of neat. And then on this project, we're also using a platform.sh, which is, they've got... Everything get based, it's built in there, they monitor your GitHub repo, you can actually use them as your Git provider. In our case, we're using their GitHub integrations. Cause the GitHub has some features that we like. But yeah, they monitor the repo, the GitHub for changes and the hooks that were mentioned earlier. Say, OK. This was changed called platform (INAUDIBLE) code and platform that Sh will build a whole new environment of our Drupal instance and their server as well. For that one, you can actually log in and test the one I mentioned in Lando. In GitHub isn't when you can interact with. It just spins up and runs the tests. But on the platform that is each side, you can actually jump in there and use it with your new changes automatically deployed.

You just... if you need to run like a composer, install script or something, you put that in your platform that's sh configuration file and the YAML file, you define what commands you want. If you want to run a config-import (INAUDIBLE) things like that. So, it runs everything for you and your environments., they're good to go. And then when you merge your pull request into your main branch, you actually get... They actually take that environment that they just built, they well, actually they merged the code in the platform. That is it. So, they take your new main branch, do that same build process, and then once that build process is finished, it's (INAUDIBLE) container based will actually pull down your currently running one and just replace it with the one that just built. So, it's basically like an instant deployment. It's not instant the sense that it instantly builds, but once it finishes building, you don't have to take down your site while that build is happening. (INAUDIBLE) swap it out at the last second and then everything's up to date.

Yeah, that's basically how my workflow goes. I can show you how some of that works. If anyone has any particular questions about things that I just talked about, I can dig into that. Let me pull up, I'm gonna pull up my project code here, and lemme just look through it and see if there's anything I'd like to show.

BENJI:
At least one person during the introductions said he was interested in seeing how to set things up so that tests are run automatically, and that's something that can be done locally every time you make a command. Because, when you run, you don't wanna run a full suite of regression tests on every command, of course. But you might wanna run your linter on every command and then you can also set things up through your whatever Git hosting provider you're using. GitHub, BitBucket or whatever, you can set things up when you push a branch, when you make a merger request, when you merge request. So, maybe we should look at some of that configuration?

SPEAKER:
Absolutely. As I mentioned, a lot of my stuff is in Lando, but the concepts can... You can just be running it on your local out of this. However, whatever environment you're used to using. I'll make sure I don't pull up something sensitive here and share it. Um. Close all these tips. Alright.

JACK FRANKS:
Yeah, everyone's Lando indeed up this year, I feel like I'm the only one I've talked to all week on (UNKOWN). JD, so I heard it a year or two ago. And now I'm thinking, boy, do I need to switch back. I don't know.

SPEAKER:
But first get OP's experience, I think, you know, Git-based workflows deployments stuff is probably with Pantheon(INAUDIBLE). And the (INAUDIBLE) had a tool called (UNKOWN) Box that was Docker-based Development environment, and it was specifically set up to work with Pantheon because that's who (INAUDIBLE) was using for their hosting all their projects and (UNKNOWN) is what actually ended up turning into Lando. So, I was doing some contract work with (UNKNOWN), and that's where I first experienced that. And that was pretty awesome. And then when they came out with the new version that were supposed to be more universal work with all sorts of different environments and what have you, I stuck with it. OK. So, trying to share screen. I have really, really wide monitors, so screen Sharing's kind of funky, so let me... Pretty sure I can share just a portion of my screen. There we go. So, I just tried (INAUDIBLE). No?. So, how do I choose which portion of my screen? That's the trick. Uh, after you click here, does it...?

Well, that's the correct portion. OK. So, good. Alright. So on this project I'm working on now, I have... So, basically on GitHub, I'm not sure how GitLab or some of the others do things. In order to make use of custom workflows and testing and whatnot, you create these files in this GitHub folder and then workflows folder. I believe all requests in this case pull request defines... Let me see if I can make this bigger. Mutation load There we go. Alright. That should be better for you. Alright. So, let mee go through this. I think I have some things that you can also just as easily do locally, they don't necessarily have to be in the cloud. Like Benji said, doing things in the cloud is just one approach. You can... There are hooks in Git itself. I don't know if they're called hooks. Benji you might know better about that. Yeah. Hooks. So, yeah, you can set up hooks. I haven't done one like that in a while, so I don't recall exactly how. But yeah, if you wanna run a test in your local environment, every time you make a command or run your linter or anything like that, you can set that up.

You don't have to have it in the cloud. You can just have a run locally. You knew you passed locally, you know, that may be enough. In this case, I wanted to be able to have other team members submit their code and I wanted to know for sure that the tests have run in the (INAUDIBLE) run. And I wanted to block the pull request if any of that failed. That's why I chose to do it this way. So, yeah, and in this particular GitHub instance here, we just... You tell it that when there's a pull request, that's the end part here, you run these jobs. So, this one is tests in Lando is the job. We're telling it just to install Ubuntu. And then we set some environment variables. My code, in particular, wholesome environment variables, just so it knows where it's at and where it's running. Hyperdrive is Lando's tool. That's that's the thing that just installs Lando for you. It's a fairly simple script, but once all that's installed, we just check out the current branch. Add some keys, pull in some code, pull in the database.

And set some things up, import the database, get rid of that file and run very common to run your drush, update your database, your clear cache is config imports. And this happens inside that GitHub instance. Then Lando allows you to set... This is basically running a script that I've set up called Test, that's it. It just runs that. Let me pull up. Oh, that is glitchy. If I can get to the menu. There we go. Alright. Navigate, let me get back to you. Oh, my goodness. It's what happens when you try to do things (INAUDIBLE) I guess. Alright. Exit presentation. It's actually going to show you what commands run inside my lando. It doesn't, like I said, Lando, it doesn't matter if it's lando or not. These are just going to be drush commands. So, that's test command. Let me find a test. Uh, yeah. Test. So, I'm just running a PHPUnit test, I go, I'm just gonna post a message on the screen and I say, OK, switch to the Drupal directory and run PHPUnit. And that kicks off my test. That PHPUnit, XML files where I've configured what runs the test and yeah, it's as simple as that.

If you didn't wanna run things in Lando, like I did say, you'll spin up (INAUDIBLE) Ubuntu instance and you just simply want to run your tests there. You'd run whatever commands are needed. I said... I showed that file. The commands I was running were to install Lando and get things reported. But you could just say, OK, install composer and run composer install that do your Drupal install and, you know, maybe import your database if you need it and then, you know, maybe execute command a lot like this and it would run there. And any script that returns a failure, so, you know, an error code. GitHub realizes that, you know, it acknowledges that failure puts a big X next to the test when you do a pull request. It's probably not safe for me to get some sensitive stuff in the pull requests. I don't think... I'm not sure what's there. So I'm not gonna show you that screen right now, but, um. Yeah. So, basically, you just set up some configuration files. And GitHub acknowledges that and does things for you.

MAURICIO DINARTE:
Awesome. Thank you

BENJI:
Thanks for sharing.

SPEAKER:
And there are other services. One of the more popular ones in the Drupal world is tugboat. Tugboat's great if you're not using GitHub. You don't want to be using GitHub paid services tugboat actually is a free two tier. This feature's a paid feature in GitHub. GitLab being open source if you're not using their cloud based solution. I'm guessing that this comes with that IP, right Benji?

BENJI:
I think so. And in fact, for your personal projects, Gitab is an amazingly good deal. It gives you free... Some number of free (INAUDIBLE) more than you're likely to use on your site projects and unlimited free repositories and so forth. So, I was amazed the first time I looked at continuous integration on GitLab.

SPEAKER:
Yeah. Tugboat, it's basically just there just been a test environments. It's what if you simply test at me, It's what it uses as the back and now there's been some integration in Drupal dialogue as well to where it will spin up environments. And basically, you set up Tugboat with a similar configuration file to what I just showed you for a GitHub action. And you say what you'd like to do, how to spin up the environment and maybe you tighten your GitHub or your GitLab or wherever your repositories hosted. And whenever you make a new branch or pull request, it will spin up a whole new instance of your site with whatever changes were made there. You make a comment, it'll redo it with those new changes to that branch. Just really great if you're not using a service like Pantheon or platform datasets that give you all these environments for testing. If you are just using like a cPanel hosting but you're still using GitHub, but you'd like to automatically build test environments. Tugboat does that.

And that's pretty much all it does I think. I actually, you know what, I believe they also have some some testing in there, too. So, you can do like visual regression testing built in to tugboat. It's been a while since I've used it. But if I remember correctly, it was just like a checkbox, very or at least very minimal configuration. And you can have it run some automated testing as well.

BENJI:
I'm having those tests, Saturday Live on Tugboat.

SPEAKER:
I believe that is based on what INAUDIBLE) you end up in if you're free, maybe not forever. The paid accounts you get, or maybe it's, let's see. Processing power. OK. So, maybe as long as you have... Maybe it's how many environments you get, but I think they're persistent as long as you want them to be, I guess. I think I do recall that if they do go down, you may have to manually trigger rebuild occasionally just 'cause they are ephemeral in nature, being there in docker containers too I imagine. So, yeah, and then there's this other one that I've actually had no experience with yet, Gitpod. Does anybody look much into GitPod? My understanding is the similar idea of where you basically have your IGE in the cloud so you can make your code changes there and command and it will spin. So, you don't even have to be running any software other than a Web browser on your computer. And it'll build a whole development environment in the cloud for you and test environments for each branch. So, that sounds pretty neat, you can be using a very underpowered machine, all you need is the Web browser and all the hard work it's done in the cloud.

But beyond that, I have not messed with it yet and I don't know a whole lot about it. Acquia also Git-based workflows. They don't give you the extra environments when you do, like pull requests and stuff, but if, you know, you have like your tests, your stage in your production branches, and as long as you command to one of those, they will rebuild that environment based on your code changes. And I believe they offer some services or some automated testing and what have you, but I have never used those. Oops, sorry. (INAUDIBLE) all kinds of stuff here, um. Yeah. Anybody else have any Git-based workflow stuff they'd like to share and talk about, ask about, we can look into? Alright. I'm trying to think if there's anything else I could talk about. We've got about ten minutes left in this slot.

BENJI:
Have you ever used to GitBisect.

SPEAKER:
I have not.

BENJI:
So, that's a cool debugging feature of Git. So, if you have something that worked 500 (INAUDIBLE) ago and is broken now, then it guides you through a binary search to find the comet that broke it. So you start out halfway in between and you test it and you tell Git either it works or it's broken and then it looks in the appropriate half and checks out a comet for you and you test it and decide whether it works or not. 15 minute session on GitBisect. Is that a recording? (INAUDIBLE) says yes.

SPEAKER:
Alright. Yeah.

BENJI:
yeah, it's pretty cool.

SPEAKER:
Yeah, I heard of it. I didn't really understand exactly what it did and didn't look into it beyond that. It was a useful tool. Right.? So, yeah, that's good to know. Antonio.

ANTONIO ARAGAO:
HI. You're listening? I have a very basic setup, I just built a small Website. So, what they do (INAUDIBLE) is I have one project that is like my own distribution. So, it's where I put at just the basic sketch(INAUDIBLE) composed file. So, every time I create a new project, I just go (INAUDIBLE) database and all the configurations that I made (INAUDIBLE). And unfortunately I have a very basic (UNKNOWN) posted. And when I put my work on the small Website so, I don't have as a stage access. So, for each project I do need to have another Git with all files. All the files from the merge of everything.(INAUDIBLE).

SPEAKER:
Interesting, so. Yeah, I wonder if there's... You're doing all of that manually,?

ANTONIO ARAGAO:
The basic, yes.

SPEAKER:
Yeah. And I wonder if there's... I'm sure there's some way you could script something.

ANTONIO ARAGAO:
Well, yeah, but at the moment,(INAUDIBLE) directly from Lando to the website. So I just pushed it. And all that changed (INAUDIBLE). So, I don't need... Only when I installed new (INAUDIBLE)

SPEAKER:
Yeah, I wonder... Yeah. If you don't need (INAUDIBLE) tools necessarily, you can script a lot of those things on your own machine, if it's a small project that it's just you working on. I don't know if you were here when we mentioned Git hooks and Git itself, you might be able to look into making it to where when you make a new branch or if you merge a branch where maybe you will run a script and automatically look for code that needs to get FTP to the server from your local if you're the only one working on it. Might be an interesting way to do some some automation there. Alright. So, just a few minutes, a couple of minutes left. Yeah, anybody else? Anything to add or share? Anything? Questions? If not, we can probably wrap this up. Alright. Cool, thanks. Thanks for coming, guys. I will hopefully see you guys around camp.

MAURICIO DINARTE:
Thanks for organizing.

SPEAKER:
Thanks for coming. Bye bye.