 Hi, my name is Jay Flouns, I'm a Solutions Architect here at Red Hat and today I wanted to give you a day in the life of a developer, the developer experience in OpenShift. I wanted to use a story to illustrate this. So we're going to start off with a broken build. Let's say the team needs some help fixing the build. They haven't been able to figure it out themselves. So they call in Billy to help out with this. We'll take a look at the Jenkins build report to get an idea of what's wrong. Then Billy doesn't have this project set up on his laptop and it would take a bunch of time to make that happen. So instead he's going to open up a code ready workspaces that will magically have everything all ready to go for him. He'll play with it, see where the issue really is, fix it, then run the application as well as run some selenium tests to validate that the application is actually working correctly before committing and pushing to source control which will trigger another pipeline run and we'll walk through that pipeline run to see what happens. So let's jump right into the developer view of the OpenShift console. So the topology here is where you're normally deposited to when you jump in as a developer. This screen feels a lot to me like if you are entering a mall and there's right there at the mall entrance, there's the map for everything you need to find in the mall. That's how I feel about this topology here. So this particular project in OpenShift contains all of the application development infrastructure required for working on a project. For example, we have our Git local here. You could have your Git external just to make things simple for this demo. I have GOGS actually installed as a Git repo inside of this project. I have our Nexus repo. We're going to pull all of our dependencies through Nexus as well as we're going to publish artifacts to Nexus. You can see we have Jenkins over here. I have a Selenium grid set up and we also have code ready workspaces. So walking through our scenario here, Billy would click on Jenkins here to come and see what the actual issue is that he's been asked to come get involved in. So we come look at the build report and we can see we have a test failure. We can click in here and we see that this is one of the Selenium tests and it's failing to find an element. So maybe somebody's changed something and neglected to update the tests to be able to find the element so the test can keep going if that is if you're familiar with Selenium tests. If not, maybe go and take a look at Selenium. It's very, very interesting. So if we go back to the main report here, let's go ahead and create a code ready workspace. This link is pretty interesting right here. If you can see the in the bottom there, the URL that this is going to go to. So the first part of that URL is the code ready workspaces dashboard. And then we're going to use a factory. So just the path that we're calling there is just an F short for factory. We're going to give it one parameter, a URL to the raw dev file that's contained within our source control repository. And that dev file defines what makes up our workspace. So let's go ahead and click on this and you can see it's starting our workspace here. So I actually have one workspace already set up running to go and there's a quota that says I can only have one workspace. So that was another thing that I wanted to show as we go through. If you're coming from more of an IT ops background, you have the ability to put in quotas to limit how much resources developers can take up. So I can only have one workspace running at a time. So I'm going to jump into a preexisting workspace that I have here. And you can see that I have our project already pulled down from source control. I didn't do that. That's part of what happened when code ready workspaces created this workspace for me. We'll go ahead and take a look at the dev file right here. You can see it specifies the project to go and pull down where to get it from. And since I had our get repository as part of the OpenShift project hosting our development infrastructure, you can see I used a service DNS URL right here to go ahead and grab the project get source. You can see as we come down through the the dev file that we have some plugins. I have an endpoint defined. This is going to be important a little bit later in the example where I am going to expose something listening on 8080 that's discoverable in public that will allow us to be able to run Selenium test against it. You can see here's the container image that we're going to be running out of. And it's a Java 8 container. And I have some environment variables set up. For example, the web API URL. This is going to be where when we run our project locally and we're going to look at the web application that we're running locally. This is the URL that it will be exposed on. So I have that listed as an environment variable for Gradle to quickly pick up. This is a Gradle project as opposed to a Maven project. Any which will work. And we have a few commands as well already preconfigured and in our project here. Gradle run, Gradle web test and just Gradle test. So let's say Billy wants to come in and play with the application and feel the problems experience the problem locally. So we will run a task. We will go ahead and run the application locally. And you can see that it has detected that we are now running the application on port 8080 and wants to know if we want to look at it. Yeah, let's go ahead and and review that. There's our application. It's a little small there. So let's open it up over here. Great. I'll close that window. And if we run the tests also while it's running the test there, let's review the Gradle file so you can see this little bit of code right here. We're going to see if that environment variable that I mentioned earlier from the Dev file, if it does in fact exist, we're going to use that as a property that we will pass to our Selenium tests to be able to point to Selenium to that URL to do testing against. If it doesn't in fact find that environment variable, you can pass this property at the command line, which is exactly the type of thing that Jenkins can do to be able to find the URL to test against when it's going through the pipeline. So right now it's executing Selenium tests. I'm going to jump back over to the topology here for a second to show you we have a Selenium grid set up. So I have a Selenium hub right here. He controls several nodes. This is a Chrome node. This is a Firefox node. And through my tests I can say what type of browser that I would like to be able to test through the Selenium grid. I come back over and see that it has in fact failed the tests. And there's a report that's been produced that we can view. So let's go. Let's go look at that report. Click on this little button over here. It'll render it for me. And we can see we do in fact have the same failure locally that we were looking at in Jenkins earlier. So let's take a closer look. It was not able to, it timed out waiting for this element here. Find owners. So let's go look and see what the problem is. It's trying to find owners right there. I see find owners. Ah, it's a casing issue. This is lowercase. And that is uppercase. Looks like somebody changed the casing trying to make things more consistent. I know that this is the source for that as well. I find owners and there's still a difference in the casing here. Let's see what's needed to fix this. I think I should make that uppercase to make this consistent. And we will also change this to uppercase. Now I'd want to retest at this point, right? So I still have my application running. Come over here to the Gradle Run tab where I ran that task. And I'll do a Control C. And we will terminate that process. If I come back over here now, we can see that it's no longer available. So I can come back and run the application again. Now that it's up and running, let's run those web tests again. Hopefully they'll succeed. And we can commit and push and follow the build. It says it was successful. We look back at the report. You can see it's 100% successful there. So let's go ahead and stage these results. Fixed case. It's our message. And we are going to push. And that through a web hook initiated this build right here. So let's take a look at the Jenkins file while this build is occurring. So we're going to version the app. We're going to build the jar. This is a Spring Boot application. So we'll build the jar. We'll run some unit tests. We'll do some code analysis. We'll publish that jar to Nexus. We'll build an image. We're going to deploy it to a dev environment. We'll run our web test against it. And then we should be asked if we have permission to publish that to a staging environment as well. So let's jump over to the Jenkins file. Interesting things to point out here in the Jenkins file. If you happen to use a Jenkins shared library, you can see I'm doing that here. It's not essential, but it's perfectly compatible here. I'm using a declarative pipeline. So I have declared my agent because this is all happening in OpenShift Kubernetes. I have the ability then to say in my pipeline what containers I want to be used while I'm building. So of course I need to have a JNLP container just to have a Jenkins agent to run my builds against. But I can have n number of additional containers to run tasks in. So I've named this one Java simply because it's the same exact image as we were using in the dev file. So we shouldn't run into any of those issues where, hey, it works in my environment and it doesn't work in the Jenkins environment. They are exactly the same. So again, I've named that container Java. So when we come down here to the build app stage, you can see I'm going to execute my Gradle command in the Java container. I'll do the same thing with running unit tests and we're enforcing code coverage here with ChakaCo. I'll publish those results in the Jenkins job. Then we'll do some code analysis with Sonar. Publish that jar over to Nexus. We're going to build our image with a S2I approach. We're going to use the jar that was built here locally. We'll publish that to our dev environment. We'll run our web tests and publish those results as well to Jenkins. And then we'll ask for permission to deploy to staging. And we have a post build section where we'll always construct a URL to be able to allow someone to create a code ready workspace from there. And we have some nice improved error handling here at the end for being able to identify where an issue is if there is a broken build. So let's go back and see where we're at in the process. You can see we're running unit tests at the moment. We'll go ahead and jump over to the code analysis even before we get there. So if I come up here, here's SonarCube. I can click on this to go to the URL. And we'll go ahead and jump into our project analysis here. And you can see all the nice statistics that are being gathered to be able to maintain the good quality of our code here for our project. And we have made it to the part where it's gonna ask us to promote the staging. So let's do that. And there we have it. We have a complete build and we were successful. Thanks everyone.