GREG: I want to bring up Brad Abrams. He leads the Product Management Team for our Developer Experiences group, and he’s going to give us a demo of Zero to 60 on the Cloud Platform showing these productivity features. Brad? BRAD ABRAMS: Awesome, thanks, Greg. GREG: Do you need that? BRAD ABRAMS: No, I don’t need it. So in his copious spare time, Greg’s been building out this Cloud Event 2014 application, but he ran into a little snag, and he asked me to use my programming prowess to help him out. So what we’re looking at here is the Google Developer Console for Greg’s application. But before we drill into the console, how many people are command line fans? How many people are more productive on the command line? Let’s hear it, OK. GREG: Yep. BRAD ABRAMS: Great, yes. Me too. So we’re going to start there.
I’m going to show you our new gcloud command line tool. The reason I’m more productive on the command line is because of keyboard shortcuts like Tab completion. So I can just say “gcloud,” Tab, Tab, and that shows me the list of options that are available there. And then– if I can type– a Tab again completes that. Oh, yeah. And then what were the options for components? I can’t remember. Oh, right. List is the one I want.
Tab finishes that out. So pretty cool, huh? OK. Oh, fine. OK. All right, so we have a set of components that are available. I could add, remove those, but I have what I think I need there, so we’ll clear that. And I’ll do another gcloud command, and we’ll go ahead– cloudevent2014– we’ll go ahead and bring down code that Greg’s already started onto our local workspace so that we can start getting started with this. So let’s take a look at what Greg’s already got. I’m going to use my second favorite editor here to check out Greg’s code. And there– Greg, I think I see your problem. You forgot to give it a title. So let’s see if we can do that, so GCP Live!! OK, just save that. Now, we’re going to use Git to commit that to our local repository. How many big Git fans are you– use Git? Yes? Awesome.
So I’ll do a git commit, and I’ll say, add a title– or whatever. GREG: Or a “tite.” BRAD ABRAMS: And then I’m going to go ahead and do a git push. So when I did the gcloud init, I initialized my local workspace with the remote repository that’s hosted for us in the Google cloud. And now, I’ve gone and pushed that up. So if we switch over here to the console, you’ll see– when I refresh this– that our new source code viewer in the console has that change that we looked at. There it is– “GCP Live!!” And now if I switch over to Releases, we see this is the Git URL that we offer as part of every developer console project.
You get a free, private Git repository that’s accessible to all the members of your development team on this project. GREG: Now, that’s really cool, and a lot of people do use Git, but a lot of people also use GitHub– whether it’s for public open source projects, or even for private repos. So is there support for that too? BRAD ABRAMS: Absolutely, Greg. At Google, we are big fans of GitHub. And so– GREG: How did I know that? BRAD ABRAMS: We’ve gone ahead and added a Connect a GitHub button. So all the features I’m going to show you work great if you’re using a GitHub repository or one of ours. So regardless of which you use, as a post-commit action, you have your choice as to what happens. We can do a build, run a set of unit test before we deploy that into production. In this case, we’ve set it to build with Maven, run unit tests, and then deploy to our cloud platform.
To give you a peek inside– a little bit about what’s really happening– when we configured that build, what we did is we spin up a Compute Engine instance, and we installed, on your behalf, Jenkins, Maven, JDK– everything we needed to do reliable builds. And then when that git push happened, we pulled down all the code and did a clean build. And then when that build passed, we ran all your unit tests and then pushed it to production. So you can be more sure you get a safe, reliable deployment. And you can see, as I practice this demo, the spikes in the build machines. So if we switch back over to Cloud Deployment, you can see our release history. And what you see here is that we added that title, we did a build, test, and we deployed that into production all in the time we’ve been talking here.
So if we switch over and see Greg’s app– Greg, it looks like a little meme application. That’s kind of cool. And it’s going to refresh with– and we see these. Here are the memes you have. Yes. That’s cute– petabytes of data. And there’s the title that we added. That’s great. I’m interested in what our top memes are, here at the Cloud event, so let’s check those out. Oh, Greg. You have a server error here. A 500 server error– that’s not good.
These kind of issues are hard enough to debug when it’s on your local machine, but when you have an issue like this in production, it’s even harder. So to give you a sense about debugging this in production, I’m going to switch over and give some simulated load– so just going to throw a lot of traffic at that site. I saw some of you copying down the URL, so you might be throwing some traffic at it as well. So we’ll go over and look at how we debug that issue. So I’m going to bring up the new unified logs viewer, and we’re getting a log entry for every request that comes in. And you saw– I just threw a bunch of requests at this thing. And we’re aggregating all those logs across every front end instance that were spinning up into a single unified view.
And so now, I can just scroll through here. And notice, as I’m scrolling, it’s loading new logs, so it’s easy for me to find logs that I’m interested in. I can also filter these. Or in this particular case, though, I want to look for a status 500, because that’s what we saw– the 500 server error. I can also come in and filter by date and time. So if I get a bug report at a certain time, I can narrow that down pretty easily.
These filters can be chained together with “and” and “or” so you can get exactly what you want. OK, so here are the errors that we’re hitting. And I can see, Greg, the problem here is in this ominously named method– getMemes_Buggy. Hmm, that must be the problem. GREG: I had to make it easy for you to find, Brad. BRAD ABRAMS: Yes, I appreciate that. So speaking of finding that, you’ll notice the next thing we want to do, as a developer, is jump into the source, because that’s where we’re going to be able to fix this problem.
But I have all this context loaded in my head. I need to get to the source quick so I can start bringing that to bear. So what I’m going to do is– notice that right here, this is actually a hyperlink. So if I click right on this hyperlink, it brings me into the console, into our source code view, with exactly the version of the source code that was deployed into production and that line of highlighted.
Pretty useful? So at this point, we could drop back to the Git command line. We could pull that file down and start operating on it. I can click on this Open in IDE button and use a variety of third party or Google provided IDEs. Or because this is a very quick change, I can just click on Edit, make this change right in the browser, and go ahead and do a commit. And we’ll just say “Fixed Greg’s buggy code,” and we’ll deploy that into production. Now, how many of you who have been debugging a production issue, and you’ve ended up SSHing into a production machine and twiddling some config file or messing with some PHP code? Who’s done that? Yes, I– who’s done that this morning? OK, a couple of you. And that’s maybe not the best idea, and that is not what we’re doing here.
We’re actually committing this change back to the production Git repository. That change is attributed to me. It’s repeatable. All future deployments will have that code as well. And we’re running that full-release pipeline. We’re building the code on a clean machine. We’re running all our unit tests, and we’re deploying it only if all those things pass. Now, that takes a minute or so for those things to happen, so let’s see if we can view that deployment in progress. So let’s open that in a new tab. And we should see our new release. There it is. We fixed Greg’s buggy code. Notice, it’s already built and tested that in just this short time, and we’ve deployed that out into production. So if we switch over now and refresh this, we should see the top Cloud memes. And of course, they’re all Jeff Dean memes.
Guess that’s how it goes. So what you’ve seen today is it’s very easy to use tools you already know and love like Maven, Jenkins, and Gradle to be able to target our platform. You’ve seen how easy it is to get reliable and quick deployments with our new continuous integration system. And finally, you saw how easy it was to find and debug an issue in production and get that fixed quickly.
Thanks, Greg. GREG: Thanks, Brad. .