Top ways to deliver your code to the cloud

Sure. Great. Thanks. Hi. Brian Benz, I’m a cloud advocate at Microsoft. And been working there for eight years now, specifically, mostly on Java on Azure, but also DevOps. So very glad to be here today. And we’re going to talk about… I’m going to show some demos with GitHub action and Artifactory working together.

Awesome. All right. Melissa McKay, as I said before. I’ve been with JFrog now for almost two years as a developer advocate. Prior to that, I was a developer. So I often approached things from the developer’s perspective. DevOps was a relatively new to me when I started. I did have a few years of experience on a DevOps team prior to becoming an advocate. And that’s what I’m going to speak to today, to begin this topic with Brian.

First of all, why should a dev care about DevOps to begin with? And this was something that was surprising to me, actually, because I came from the culture where developers were in a silo, they were on one side of the wall. We really weren’t involved in deployment at all, we weren’t really involved in the decisions made on how an app was configured in a production environment, things like that.

We just focused on our IDEs every day we wrote code, we fixed bugs, we made features, and all of that stuff, but we weren’t really involved in the end product. And it turns out that there’s a lot of reasons why we should be involved at the very beginning. And that’s the whole point of DevOps and the intent of DevOps. Even though there’s a number of different ways of doing DevOps, it’s one of those terms that can be overused and possibly done wrong on a team. I definitely have some stories to back that up.

But all in all, the main reasons why this was such an important step for me was because I realized that some of the coding decisions that I made in the beginning really had a lot to do with how the app was going to be deployed. And that’s where the whole microservice boom came in, for example.

So I’m just going to go through a quick definition of DevOps. This is going to be really simple, because it comes directly from Wikipedia. And then I’m going to describe some of the components that we’ve all kind of settled into. And in all of our experiences with DevOps and building pipelines, I’ll touch on a little bit of a value stream just to give you an idea of what you should probably be focusing on in your teams. And then Brian will follow up with an implementation. And we’ll have some discussion about the reality behind implementing DevOps.

So first of all, these are resources I always throw to everyone. Pretty much any, any talk about DevOps I give is going to have these resources in it. I love these books, the Phoenix Project, the Unicorn Project, and the DevOps Handbook. These were some of the first books I read about DevOps in there. Definitely staying on my bookshelf. I actually need to go back and review some of these, it’s a been a couple years now since I’ve read them.

But what makes them interesting is The Phoenix Project is it’s a fictional story but it is in a novel format. And it’s about a team that is definitely having some issues with their product and with their delivery, a lot of efficiency issues. And it talks about an executive perspective on how to approach those issues and how to make some changes just to make the flow better. Each stage of delivery can be thought of as something that can be improved upon introducing concepts like making self-serviceable, for example, being able to provision machines on your own, things like that. All of that is discussed in the book.

The Unicorn Project is the sequel to The Phoenix Project. And that one is also in novel form, and it’s from a developer’s perspective, you would see a lot of the same characters portrayed in that book that you see in the first one. So pretty interesting read. And then The DevOps Handbook is basically what it is a handbook. Some concepts are introduced in that book. It’s more like a manual to follow. Definitely check those out. Available on Amazon. Worth the read.

This is a screen that I see often in our corporate decks. And I like to show it here just to show how overwhelming the DevOps space can be. Not everything is included in here, for example, and I’m a bit biased. Being with JFrog, I’ve got Artifactory in the center of everything. Artifactory can be considered in the center of everything as your storage of all of your binaries and all of your dependencies that you use for your project throughout the life cycle.

So as a developer, when I first started and when I first believed that that’s all there was, I remember way back over 20 years ago, I started as an intern on a team and I was not familiar with continuous integration. And I hope that our audience is familiar with that. Everyone should be using that. But this whole idea of being able to have a common place for your source code, being able to have automated builds so that when you check in source the builds automatically happen, tests are automatically run, and you can immediately filter out problems right there in the beginning of the process. Because there’s a lot more that needs to happen after that.

And you can see in this diagram, all these little steps are numbered. They’re pretty tiny and hard to see because there’s so much involved, but all of the steps involved around deploying to test environments, for example, making sure that you’re using the appropriate package managers, your build tools on your CI servers, things like that, moving your products along into testing stages, into staging, and then finally into production. That also includes all of your provisioning tools, which involves automated deployment as well. And those were all new things to me as a developer being introduced in the DevOps space.

That said all of this information does not need to be known, you do not need to be an expert in everything. That is the point of a DevOps team, right? You have developers, you have operations personnel, you have the security team. All of those folks should be communicating together. No more silos of working alone, but all of those boundaries between those areas, you need to have communication there so that this entire process is smooth.

Over time, we have created these buckets now of basically the basic at concepts and the basic components of a DevOps environment. And I was on a panel recently and I liked the metaphor that came up about car manufacturing and how, right now, there’s so much more coming down the pipe, a lot more products and stuff that are coming in as far as DevOps is concerned. And it can be compared to car manufacturing. How many of us would be driving cars around today if we had to build them ourselves?

So where I’m going with this is we need those car manufacturers in the DevOps space. And that’s what we’re starting to get to. We’re starting to get to these frameworks, these products that we can use that solve all of these problems for us and put them all in a nice, neat. Some are opinionated. So you don’t have all of these choices to make. You can get everything done from beginning to end and have a certain skillset to focus on. And this makes your team more efficient and faster at your software deliveries.

So these components are all part of your pipeline. For those you that get overwhelmed just by the word pipeline, just understand that that is also an overused term, especially with products that have the word pipeline in it. A software pipeline is just the steps you take to get your product from development, all the way to production. And these components are involved in those steps. You’ve got your source code repository. You have your continuous integration environment, which includes your automatic builds. You have your package managers, you have your security scanning, which can happen in either a testing stage or even at the end. Best to have that as close to the beginning of your pipeline as possible. And then you have continuous deployment, the ability to make a change and have that change flow all the way to the end to release your product or your application out there.

Lastly, this is the last thing I want to bring up before I pass this off to Brian so he can show us some implementation details. You need to decide what you really care about. I mentioned before that in your pipelines you’re going to need to make decisions on which products you want to use, what skill sets on your team you want to take advantage of. And there are some pretty awesome frameworks out there that will address those concerns for you. And Brian will show us an example of one of those.

But ultimately, you need to find out what you care about. And make sure that when you’re designing your pipeline and you’re considering how to deliver your product or your application, find those steps that are slowing you down. You may have some opportunity to automate in that portion. You may have some opportunity to create some self-service mechanisms for your teammates. Ultimately you need to decide where to spend the money and where it’s going to be worth it for your team. And that might not be every step of your pipeline. You may need to focus on one to start with.

This slide is a picture of my car. It’s a good visual on what you need to focus on. I need this car to get me to where I’m going. It’s not worth much. And it’s certainly not worth repairing the little fender bender I got into. So I got a $10 bandaid from Amazon. And that’s good enough. So my pipeline is solid. All right, I’m going to pass this off to Brian. Show us some details of how to actually implement this.

Cool. Great. Thanks, Melissa. Great to be here. I’m going to talk a little bit. I’ve got a few more slides and we’re going to get to the demo. But before we get to the demo, I just need to talk about the target environments that you can use on Azure. So the demo I’m going to show today is Artifactory working with GitHub Actions. And it’s going to be deployed in application to Azure. In this case in Azure Web App.

The target environments that you can use, though, we have multiple. Of course, we have virtual machines, Kubernetes service, we have something called Azure Spring Cloud, which is a managed Kubernetes service with spring built on top of it. For Java developers, we have Red Hat OpenShift, and we have several other things you can use for delivering your applications, especially containers. Kubernetes have something called Azure Container Applications, which is a scalable way to take a container and just publish it on the web.

But in this case today, we’re going to focus on Azure Web Apps. And Azure Web Apps are actually fully managed pass. The fully managed pass itself, you can deploy applications the way you want, it integrates with Eclipse in IntelliJ, and VS Code, which is our free open source text editor that you can use. So the application I’m going to show today is Java, but you could use any type of application to run, basically on Azure Web Apps.

It has built-in CI/CD integration through a couple of methods. The first one is through GitHub Actions and then we have something called Azure Pipelines as well that you can use. And both of those integrate with JFrog products, including Artifactory and x-ray, and also the CI/CD tools that JFrog offers as well integrate well with ours. You might want to use, for example, if you have Jenkins or some other already pre-made tool that you’re using for builds and testing, you could also use JFrog’s CI/CD tools and integrate those with the tools I’m showing you here for releases.

So what’s cool is any CI/CD tool external is great for builds and testing if you already invested in that, but then you can use our tools for releases and deployments. And the advantage there is it’s kind of inside the Azure fold. So if you already have an Azure account, everything is integrated, your identity is known, and you don’t have to do a lot of identity management and setting up for security and auto logins. So that’s kind of cool stuff. But the fully managed pass has the CI/CD via GitHub Actions. And it also has passes via Azure Pipelines. And you can deploy those things on a multiple scaled and multiple platform level inside of Azure. And I’m going to show you some demos of that in a minute.

Today also, I’m going to show you Visual Studio Code as I mentioned before. It’s an open source free text editor. You can get at codevisualstudio.com. And we’re going to use GitHub. So we’re going to use GitHub Actions, and of course a repo for storing data and code that we’re using with this application. And then we’re storing some of the dependency artifacts using JFrog’s Artifactory.

Couple things you might not know about that I always like to mention because they’re cool is GitHub Mobile. So GitHub Mobile is a way to actually kick off CI/CD tools from your phone. I’ve done this before. When I’m on vacation and I didn’t bring my laptop and for whatever reason I need to do something for compliance, update an app, you can actually kick off things from GitHub Mobile, which is pretty cool.

And last but not least, I did want to mention Codespaces. So Codespaces is a way to actually build your applications and create a container definition inside of GitHub. So there is a way to actually generate a fully integrated developer environment. It actually takes a clone of your application, runs it in a container. And you can actually edit it for many browser using Codespaces. So that’s kind of cool.

So let’s get into the actual application itself. And I’ll show you what I’m going to show for the demo today. So this is the… I’m going to start with the application. So this is the application. It’s a Java application. It’s a spring boot application. And it’s a silly little thing. We’ve got this developer advocate mascot that we’ve got at Microsoft called Bit.

And the reason why I want to show you this is we have something called a feature manager. And this will be obvious why this is important later as I show you how to automatically custom configure applications when you’re deploying them in GitHub Actions. So inside of here, we actually have this thing called feature manager. And if you go down to configuration explorer. So inside of here, there is a beta setting.

So what a feature manager does? It allows you to do things like AB testing in production. So I’ve got this feature called beta. It’s enabled right now. If I disable it and I go back to my application, you’ll see a different version of this eventually. So I just need to refresh it a couple times. There you go. So it gets rid of the bit. It’s just a silly little example here. And it automatically does this. The cool thing about this is I can just turn this on and off. And each time I refresh this, the user would see a new version.

So you can set this up so that 50% of the people see the old version of the application, I’m refreshing it, refreshing it, and 50% of the people see the new version of the application. So you can do things like AB testing and deploying things and testing them out without actually changing your code at all. You just go into feature manager and connect it.

Now, the reason why I want to show you this, why it’s kind of unique for this application, is that this requires a custom connection string in your application. Now just bookmark that for a little while and you’ll see why that’s important in a bit, because you need to customize your CI/CD workflow, and you need to share that connection string with the feature manager from the application, but you need to do it securely. So I’m going to show you how to do that. I’m also going to show you the same technique for integrating with Artifactory. So that’s the little application. Let’s just refresh it again. There it’s. Okay. So it’s back. So I turned it off and on.

All right. So the first thing I want to let you know, and not a lot of people know about this, is you can actually set up Artifactory on the cloud of your choice. In this case, I’m going to pick Azure just because, obvious reasons, I hope, I work for Microsoft. And what you do is you just go… If you just search on JFrog Artifactory on Azure, you’ll find this, but the actual URL, we could share later. It’s JFrog-Artifactory-start-free-on-Microsoft Azure with dashes in between those words.

And the idea here is that this will get set up on Azure. Now the advantage of that is if you have compliance issues or you might have some domain issues in terms of the cloud that you need to choose, or you might just want to have it integrated with everything you have in terms of identity measurement inside of Azure, you set up Artifactory on Azure. And the locations here, it says server details, but these are actually what we call regions in Azure. And the U.S. Canada, Europe, and Australia, Asia are well represented here.

You set up your own server name, you put in your email, add a password, and you put your first and last name, and you’ll get something that looks like this at the beginning, actually, which is quick setup. When you get going with it, you’ll have your stats that gets displayed as a start. But from there, what you can do, because this is a Maven application that I’m using, I pick Maven. Okay. So when you go in here, you click on the repository you want to use. In this case, I’m just using the default Maven virtual, which is the cloud storage for Artifactory.

And then from there you click on set me up and there’s two things you can do. So for deployment, this is something that you put into your pom.xml. And I’ll show you where it goes in the pom.xml in a minute. And then in order to authenticate with Artifactory server from wherever you’re working, in this case, GitHub Actions, you say generate settings. If I type my password in here, it’s actually going to include the password. But we’re doing a demo here, so I am going to leave it as the generic version.

There’s three things that you need to have. You need to have your current username, is going to give you a username and then your password, and then the host name that you use for the Artifactory repo that you’re working with. Now, once you’ve got that, you actually just download that snippet after you put your password in. And that’s going to have everything in an insecure way. And then what we’re going to do is we’re actually going to customize that.

So that’s just a little bit about how you set up Artifactory. And then what we’re going to do is we’re actually going to move on to the repo that we’re using. So in my repo… This is a public repo. So you can go and get all the demo artifacts that I’m using today. You’ll have to set up your own Artifactory. And it’s free. So you can do that as well. But here’s the repo. And what I’ve done is I’ve actually created a settings at XML file.

So if we go into pom.xml first, the pom.xml, you put that snippet for distribution management in between dependencies and build. Basically, just copy paste the whole thing. doesn’t need any changes. The next thing I did is I set up settings.xml, but I customized it a little bit. I create what’s called a GitHub secret for Artifactory username and password and the hosting. And the reason why you on to do this, you can actually paste the completely insecure version of this into GitHub. If it’s a public repo, GitHub will really make a lot of warnings to you when you try and push this to a repo. It just doesn’t want to do it. And in some cases, if your organization that you work for has set up security correctly, it won’t allow you to publish this.

So the idea here is you need to create secrets for username, password, and the host. And then what you do is, inside of the GitHub repo itself, its settings in secrets, you create the secrets that you need for this particular application. Now remember that I mentioned at the beginning when I showed you the featured flags that you have to have that connection string to connect the application to the host.

Well, that’s here. App configuration connection string that’s in the repo. So any GitHub action that you build can reference these secrets. The app configuration connection string and the host, the password, and the username. And this is a published profile for connecting your actual application GitHub Actions with a repo. We’re going to generate a new one of these. So I’ll show you how to do that in a second.

All right. So that’s basically what you do. So you go into, just a quick recap here, sign up or Artifactory a free account, go in and get your configuration information from Maven for the pom.xml in the settings.xml, customize those and create those secrets in your repo. And refer to the secrets in there. Now, one of the cool things here is you can, if you want to, you can actually use my settings.xml, copy this one, and just use those same variable names for your secrets. And you’re good to go. You don’t have to create this yourself like I did.

Okay. So moving on. Let’s actually see what we could do with this. If you look… This is Azure. So this is the portal for those of you who might not be familiar. And what I do in my Azure portal, you can create custom dashboards. And this one’s just for JFrog DevOpsDays. I’ve got several others. This is the way I organize my work because I’m a cloud advocate. I have different demos and different presentations, and I create a dashboard for each one of those.

In this case, my dashboard is here. And I’ve got this test web app. That’s what we were looking at up here. So this is the test web app here that we were playing around with. But I’m going to create one completely from scratch to show you how you do this as a new one. So let’s get in there and get started with that.

What I do is say, create a resource. And by the way, you can use the Azure CLI for this too, but this is just much easier to follow if you’re a newbie. So I like to give this as the demo. So we choose our subscription. If you don’t have a subscription, you can sign up for a new one. They’re free. And we’re going to go to my resource group. So everything in Azure has a resource group. And that’s just a way of organizing and compartmentalizing your applications and making them organized. So I always know that all my demos are in DevOps or JavaShops, for example, which is my resource.

And today we’re going to say devopsjfrogdemo. How’s that? And I spell JFrog correctly? There we go. And it tells me that that’s available on Azure website.net, because we need to access this from the web. And we’re going to publish code. We’re going to a runtime stack. Not surprisingly, we have lots of .net availability. We also have Java, Node, PHP, Python, and Ruby. In this case, we’re going to choose Java 11. And you can use the embedded server. You can use JBoss, EAP, or several versions of Tomcat. We’re just going to use the Java SE embedded server. And we’re going to run this on Linux. More than half of… We have a ton of Linux running on Azure. Actually more than half of our VMs, people are not always aware, are actually running on Linux on Microsoft Azure. So that’s kind of cool.

And I’m going to say West US 2 for our location. These are our regions. For all intents and purposes, a location that we have. And then I choose my plan. I’ve already got a plan preset up, so I don’t have to do that for my demo. And then I can just review and create. But I want to set up CI/CD. So we’re going to use GitHub Actions for this. And what it’s going to do is it’s going to create a generic action for me to use. And it might ask me to authenticate. No. Okay, cool.

So we’re going to use bbenz as the organization, which is me. And we’re going to use test feature flag as JFrog, which is a repo I showed you earlier with the secrets and the settings and the pom already set up. And we’re going to use the main branch. And what this does is it generates a GitHub Action. And this GitHub Action is going to fail miserably because we haven’t configured it properly yet, but it’s a great way to just start. You’ve got a basic template and then you can add things to it. Let’s do a review and create. All right. And let’s go ahead and create that.

So, as I mentioned, this is deploying. And there are two… There’s one thing I need to do the app service to make this work. And then there’s another thing that I need to do to connect this to Artifactory, as well, in terms of the GitHub repo. So while this is running, this is the Azure dashboard. If I go back up to GitHub and I look at my repo, if I go into actions, oh, it’s trying, it’s trying is very, very diligently. Trying right now, but it’s going to fail because this code actually won’t work. So I’ll let it just fail for now. We’ll come back out for that. But let’s set it up so it will.

All right. So let’s see if we can find this one. There it is. So what I did here, I went from… I should mention. So this is actions. This is the action running. And then what you do is you go over to code and you go into GetHub workflows. And if you look at JFrog demo, this is the YAML that just got created for this. And this YAML is going to fail miserably because it doesn’t have any reference to Artifactory and it doesn’t have reference to the secret, either that we need.

This will actually kind of work in a certain point, but it won’t do everything. The nice thing is it’s got the secret for my new… This is the published profile that we created. So if I look back in my repo settings secrets. So we’ve got a second published profile here. It’s created one minute ago. This is what’s going to connect this Azure application with the GitHub Action that we’re building.

So customize it, or go back to code. GitHub workflows. I’m actually going to go into Visual Studio Code now. And I am going to pull this into my local version of this application. So Visual Studio Code has built-in Git commands that you can use. And in this case, what I want to do is I want to pull in this code. So if I look here, I just pulled this in through the GitHub controls. Now I will have… In my GitHub workflows, there’s the actual, it’s the actual GitHub action that we’re going to use. It’s a gamble file. And we need to add a couple things. So let’s go ahead and add those.

So the first thing we want to do is we want to add that connection string value to the top here. So the application itself will connect to the connection string. So that’s there. The build will fail unless this is here because it relies on the connection string. Not the greatest thing if you’re in a production environment, but it’s a demo. So what the heck?

The next thing you want to do is when you go down to deployment, it creates this step here called build with Maven. There it is. So build with Maven just does a run Maven clean install, but that’s not what you want to do. So I’ve got a custom version of this. And you can go into my repo later and you’ll be able to see this workflow in there as well.

So… Oops. Let’s not do that. Let’s not make YAML angry. Let’s do this. So yeah, I did it anyway. Oh boy. Okay. All right. Got to customize that YAML so it’ll actually work and not choke. All right. So that’s that. So this should actually work now. When we build this and push it, it’s actually going to configure another application run. And it’s going to deploy. And it should deploy out correctly, because we have the correct published profile here. And what I’m going to do is I’m going to set this up. I’m going to save it.

And then what we do in GitHub Actions. Inside of here, as I mentioned, we’ve got built-in Git controls, add Artifactory demos secrets. Okay. So what I’m doing now is I’m going to stage these changes. I’m going to commit, all by clicking that check box. And then I sync the changes us with repo. And when I do this… This is locally on my Visual Studio Code by the way. I don’t know if I mentioned that.

When I go back out to my GitHub, we can check our actions. And there’s our complete failed one. Here’s the one that, cross fingers, is going to work. Five demos. Now it’s building. And while it’s building, let me describe what this actually does. Let’s go back to Visual Studio Code. So the first thing it does is it adds that app configuration connection string so it can build properly. And that’s a universal environment variable that we want to put up here.

The next thing it does is it runs on Ubuntu latest because are mirroring the actual web app that we’re using. And then it checks out the application itself. What happens is GitHub Actions run on these things called runners. So GitHub action is run in containers. And it’s not running inside of your GitHub repo. It’s creating a copy of it and running. So you can actually make changes and continue to do things, but it will save the state exactly the way it was at the moment that you kicked off that action.

Then we set up the build with Maven. And instead of Maven clean install, which is the default, we have Maven package. And I specify settings of XML. Just if you double, triple clear that we’re using that settings of XML that refers to artifact, not using the default Maven Central repo. And inside of there, you use the Artifactory username, password, and host. And then what it does is it actually uploads that artifact for deployment. So it creates a JAR file. And it knows where the JAR file is. It posts the jar file to the runner. And then it deploys Ubuntu latest. And it uses that published profile that we created when it was automatically generated when you connect to Azure DevOps.

So let’s go in and check to make sure… Yay! So the build succeeded. So the setup ran and build with Maven, it actually works. So you’ve got downloading. And one of the things I wanted to say is I was really frustrated about this, and you probably will be too, if you notice these little stars here. So I was wondering, why is it displaying, not the full URL, but these little stars? And I realized that inside what I’ve done is I created a secret inside of my GitHub Action. And GitHub will not display that secret because it’s a secret. So your username and password is set up and it’s hidden as well. You can go and you can get those.

And then it grabs… Well, it grabs everything it needs basically to build this. And hide everything in the log. Because these logs could be publicly available or available to someone in your organization that you might not know. So I couldn’t figure that out for the longest time. Why is it doing that? Why isn’t it showing me the full URL? But that’s because I created a secret. So it should have.

All right. So it looks like it deployed as well. So it actually set up the job for deployment. See, I mentioned that it runs on a runner. So the current runner version, the operating system, everything here. And by the way, you can create custom runners that run locally. This one runs on GitHub. And then downloads the artifact again. Deploys to Azure Web App. And from there, it just finishes by cleaning up the artifact and so stuff like that.

So if we actually go into the job itself, oh, we can just go here, and I click here, it’s going to actually go to the application, hopefully, but this application’s going to fail. See that application error? Because there’s one more thing we need to do. I mentioned a two-stage process. So in this case, my deployment is complete. So I can go to this resource. It’s complete, but it’s not working. There’s two different things. And then what I have to do is I actually have to set up in my configuration that string.

Now, remember we set up the connection to the feature manager, but we didn’t set it up in the application. We only up in the runner that’s used for building the application so we know it works. So the next thing I need to do is I need to copy this connection string. I’ve done it a couple times. So it’s already cached the name, but the value is here. Go look, everybody. It’s okay. You can’t see the whole thing.

So once I do this and I save this application setting in my app service… Okay. It’ll probably take a second or two, but if I go back into my app service here and I click on the… That’s a good error message because… There we go. So the application’s actually working. So we fully deployed. Let me just recap what we did here to get to this stage. We went into JFrog. We signed up on Azure. We went through the start. We got our pom.xml customized. We got our settings.xml customized. We went into GitHub and we updated those. And then we went into our Azure portal and we created a new web app and we set up automatic CI/CD, which created a template that you can use for customizing. Because it fills and deploys a lot of the stuff that you need, but it fails.

And then of what we do is we go into our settings XML, you set up the secrets, you set up the distribution management and the pom.xml inside of the GitHub repo, you set up your secrets. And that’s that. So the app configuration connection string, the host, the password, the username, and it automatically generates your published profile for that. Once that’s done, then you can deploy. And then once we deploy, we need to set up that final configuration connection string in here to make the actual runtime application work, not just build and deploy. And once we’ve done that, we’ve got the application itself.

So, hopefully, that was a good overview of the application itself and how you actually deploy things from Artifactory. Melissa, do you want to talk a little bit about Artifactory itself?

Yeah. We know now how to integrate Artifactory with GitHub Actions, but why would we want to do such a thing? Well, Artifactory provides you the opportunity to store and manage catalog, all of your dependencies, your third-party dependencies, as well as those artifacts that you create that eventually get released.

What you’re seeing right here in this repository, I just want to say that we chose this default repository. But the way that Artifactory stores all of these things, it is very easy and cheap to create new repositories that could be project-specific or team-specific, however your organization is built. I suggest project-specific. I’ve had a lot of good experience with that.

But these repositories, the virtual repositories are basically a pointer to all the repositories that you would need for a particular project. For example, it encompasses the links to remote Maven. In this example, we’re using a Java project. So we need that remote Maven Central. It also encompasses is everything that you’ve built internally. And you just have that one virtual repo that is a pointer to all of those things. So you can develop and you can deploy using the same repository.

Repositories, depending on how the remote repository is set up, you can see everything that is available in the remote repository, but only the items that you actually use for your project are brought in and stored in the cache. And that just means that subsequent requests for those particular dependencies are going to come directly from Artifactory, you will not have that second step of going all the way out to Maven Central again.

Advantages around that are, you may have some company rules around where you can get your artifacts from. You might want to have that path just go through Artifactory and know else. This is also a way to have full-fledged permissions and control over binaries and dependencies that you’re using. Whether they’re created internally or whether they’re brought in remotely, the caching is great for those instances when essential repo may be offline, for any reason. It allows you to curate the dependencies so that you could potentially have repositories that are meant for production versus repositories that are meant for research and development, per se. You may have different rules of which artifacts are allowed to be used in those situations.

You can also enforce those rules around the dependencies. You can say… For example, we recently had a log for J security. Problem come out there. And if you want to restrict the download of old versions of that particular Java Library, you can using Artifactory. And then also you have the ability to trace every build or project that uses a specific dependency. So in that same example, with blog for J, you can make sure that you have tracked down all of the projects that are using it and enforced that they use the latest version, which fixes the security flaw there.

And Artifactory of JFrog, I guess, actually created a tool that you could use for binaries to do that. Right? You can check with that.

Yes.

I was just going to mention one of the advantages here is, I’m looking at it right now on the screen, is you can see that we don’t use log for J on this particular application. So I didn’t need to go in and check my build or my pom.xml or any dependencies. I can just go in here and see why for J is not using this app. So that’s cool.

Yep. within the JFrog platform, you can set up scanning of all of the dependencies that you use for particular projects. And that is the x-ray product that we have within the platform umbrella. That can notify you of new vulnerabilities that have been found. And also you can enforce whether projects or libraries that have those vulnerabilities can be deployed or downloaded by developers.

Cool. Well, great. I think that wraps up everything I wanted to show. There is also a way I mentioned to do this with Azure Pipelines, but that’s a totally different demo. In the rest of time, we’ll stick with GitHub Actions, which I think a lot of people are using anyway.

Yeah. Looking forward to more of your stuff, Brian. I feel like there’s a lot more to learn here. Definitely with GitHub Actions. Take what he’s done here, go visit that repo, try some things out for yourself, especially working with the secrets. I think that’s an excellent approach to solving a lot of our issues.

Yeah, thanks. No, it was… Actually, I worked through several iterations of how to make that work. And this was just the cleanest and easiest, and the one that GitHub didn’t complain the most about. So that was a nice way to do it. And there’s multiple different ways you can do it. There are some plugins and things you can use to authenticate with Artifactory and your GitHub Actions, but I just found that generating the code and then just creating the secrets was the cleanest, the simplest, the easiest. And I can move that to any repo I want. So as Melissa I mentioned, if you want to look at this, the combination, this video and that code that I have on the repo should be enough to get you started and make this work the way that it in the demo.

Excellent. Thanks again. Enjoy the rest of your sessions for Cloud Days, everybody.

Thanks, everybody.