 some methods which a developer or an engineer needs to actually follow while being able to follow the process of agile and make a success. I am Shobit, I am an architect and a senior engineer at Red Hat. I am a co-contributor to OpenShift IO which is associated with OpenShift and it makes you more and it helps you be an enabled developer as part of OpenShift. So, I am going to make a few very radical statements here which is you are not agile if you have a deployment there, then you have a ceremony, people going on a Saturday to do a deployment. You are clearly not agile in that case. If you are waiting for some team who is going to sign off your build so that it can go into production. Somebody complaining, sorry my coming broke the build. That cannot just happen if you have the right process to do this. And only somebody in the team knows how to deploy and she will not leave. So we have got to change things a bit now. That should not be happening. So you might need a downtime because you need to put in some more features. There is something clearly wrong if you have got to leave that time. And yes, if you are a long time engineer and it takes you 50 minutes to set up your workspace that is very bad because you are going to have somebody leaving the team sooner or later and then you are going to have a new member join the team and your entire planning is going to be off the window just because a new member joined and it took him a full day to get started. That should just not be happening. So in summary, if these are the things which happens to you or your team, you are not an agile team anymore. Things have to clearly change. And I am going to show how being continuous is going to help you ensure that you can be agile and can truly be able to deploy every day and being able to reuse as soon as possible. Right. So the promise line is this. Every comment should have tests. Not too we can do that or only a developer and somebody and an engineering manager who enforces this within the team which means no change request is going to be accepted without tests. And your repo should have that on field of course. That is a technical thing to ensure that your payments get triggered. Your change request should trigger tests. Every module master should actually be deployed in an environment. Which means if I know that my change will be deployed somewhere, I know somebody will be screaming at me if I break things. But if I know that my change will remain in master for the next three months, before it will be actually used, I am actually going to be okay being careless with my comments there. Right. Every pressure will be deployed in this. If you make a fix today, there should be no big reason why it cannot go to production today itself. Right. So let's see how something will be working on OpenShift. I can do it all for you. You can of course do it in the terms of other open source projects as well. But this is one open source project being hosted as a product which can actually help you do this. I try to see how I am going to like the one that else I am going to call. Right. So let's actually start with, you know, day one, you create a new application with typical things. So your typical things, if you create an application, you choose what kind of rest area you want to be in. Let's say you are supposed to work on a backend service. And then you choose what kind of framework that will be. You move on to select some dependencies. For the sake of simplicity, we will skip this. Go on to choosing what kind of pipeline you have. Which means, let's say you want to set up bins automatically because that's the first thing you should be doing. That's not something that's going to come on day 10. It's just going to be zero itself. You choose, it's okay. Your bin deployed to a staging environment and if somebody okays it, you're going to deploy it on production environment. And I've made all those choices, what kind of code base, what kind of Jenkins pipelines or bin I want. And then I'm going to go ahead and set up my application. On day one, it should not be taking longer to set up a very bare bones code base which does a hello world rest area to me. So you set up an application and this should effectively set up your basic code base so that you can get going. This should have your Jenkins webhook setup, or whatever system you're using. You should have your big pipeline setup and you should have the whole process of deploying Cora and also setup as well. This one is super powerful. The bunch of process actually went and created a repo right away from this application itself. This is your bare bones rest API which has a basic stuff built in. You can also check this code out and run it locally if you want, but then you don't have to. You're right where I'm going to show how you can actually test it out and run it on a build and deployment environment right away to say that this thing works. So the next person who joins in your team does not complain or whatever code he gave me does not work. It actually works. So we go ahead and now we kind of take a look at what's happening after we just get to the code base. It's the first zero at day. You should have your code base built successfully. This page lists all the different code bases I have. This is the code base which got created for me right away. I've got pipelines, deployments, and for the pipelines here I can see a new build has been triggered already which means I just made a code base. It seems like my webbooks are already configured in there because the system did it for me. And then I'm opening a console. I see there's already a Jenkins build happening because I triggered it myself on the process but not explicitly. So at this stage what it does is it actually means that on day one you have a code base set up. You can actually tell somebody it does build as well which means the first step is a build you can release which means in an agile team you should not be spending a week on writing some code some basic boilerplate code and then in the end try to figure out how to deploy the Jenkins. That should first see what's happening. The first step is let's compare this code base. Let's say if I can build an artifact out of this. Now that's done, let's say we're actually we're trying this tiny service into a staging environment which is basically an open shape environment. And then yes, it's good. It can deploy to stage and then now I will check if I want to approve this or not. I quickly click and see if my application is working. Yes, I see I've got a decent HP booster in there where I can fill in some text and it should call REST API and actually demonstrate that the REST API is actually working. Right, so now I go back to my pipeline space for a bit and now that it's working I decide why not have a push button to actually take it to the next environment. I say let's promote it to production one. So what it effectively does is it takes my code from one environment which was built at stage one and then requires it to run and it also gives you a nice neat link to actually see if what I deploy had actually run in there. And I say yes, the same application has been deployed in a different neural network. I'm sure it's not very visible but there's a different neural network. Right, so what we need to accomplish is within minutes we have a day zero in a project done which means you have a code base, you have a bell in the check-in setup and you have to test it out when your deployments are working. I go to OpenShift online and they actually check my app is deployed there is one more running in there there is a route exposed so this kind of tells us okay at this stage we have the basic setup built in now we can give this code to somebody else to go in and explore maybe let's say I want to open up a workspace to edit and for anyone who tries on Java it takes quite a while except for Eclipse local desktop ID where we try the first time and it says get working so what this does is effectively with a click button it spawns up on your workspace right here it means your workspace is not just our base ID it's basically a full-sledged ID with a container running behind it means all the dependencies you need for your workspace everything you need to ensure you have your build, run, debug working from the comfort of your web app you don't have to do any local install at all so what this effectively does is it logs into your OSO which is an abbreviated for OpenShift Online which means it ensures that it can talk to your OpenShift Online because this one it's deployed in an OpenShift Online name space and then it goes on to ensure that it works with API works and that you have a real terminal inside the change which means if you are still developing something that means a terminal this doesn't deprive you of that this gives a terminal a full-sledged one where you can run your Git commands your Java commands, your Java commands from the comfort of the web ID so that you don't have to figure out how to install all of that in your local environment so now it's going to check out a code from GitHub and it says that code which is having GitHub has been checked out it just gives a few green texts to the developer that things have been set up for her so this whole one space took me about a minute to get set up compared this to any developer actually checking out the code I have on the repository and setting it up locally with all the conflicts with Java versions get your Mabel in place and ensuring you know all the Mabel commands etc to get it working so what Mabel does I quickly go in and open my source code and make a tiny change and make a GitHub commit from inside the workspace itself so I get to my code base where I have the rest API defined I'll make some streaming there and try to make a commit and maybe make a pull request to my GitHub repository to show that you can actually contribute to any open source project if you have all the things connected in place so I just update some response string which is going to be returned by the rest API and I'm going to control the same when I save the code when I save this recording so that's not the way it was made so I'm going to create a new branch I'm going to give the branch a new name I can do the same thing using the terminal as well down there but I know it's nice to just give you an idea for a change I'm going to open up a pull request to this change right away I just key in my title the command which is to create PR what I have to do is create a branch in my GitHub repository and at the same time open up a pull request to it and I'm going to show you all this is going to happen without you having to set up your local git repo which means you don't have to do your git add remote upstream git add remote in your personal space I just do a bunch of tics and I say ok we are good to comment this and we are going to push this to GitHub so down there on the right you see branch pushed on your origin a blue tick there is visual and a blue tick there it says your pull request has been created now let me click open on GitHub and at the same time if you if you don't believe Jollybox you actually when you enter your workspace and see you can go git status you can say it's all clear which means all my comments have actually gone up there I open my comment in GitHub and this is what I just committed and you can see down there a bill has already been triggered for the workspace it's created 10 minutes back without me having to explicitly set up their posts etc it's such a bill out there while that's happening we can quickly check one interesting thing there's a link out here which came up in this pull request by click here it's going to open me another workspace cloud workspace which means if you're reviewing my code you're going to have to check out your code in your local ID to test it out can actually click here it should start up a web-based ID full-fledged I'll actually help you to go in and change code in there if you think you need to try something out in your local ID before you actually approve it kind of take a few steps back and talk about what just happened so effectively every comment should have tests not something tooling can do much about tooling can of course check whether this change request has some tests actually check whether your pull request has tests whether that's something more of a culture that developers needs to bring in okay there did have the web-based configure that's how you saw a bill get triggered as soon as you open the pull request the change request did trigger a test we saw a yellow thing in there much more should be deployed we haven't done that yet every deployment should have production void which means if you know my change is going to be deployed you will be careful about ensuring a change of production quality and yes your debt could be deployed one day if you have the rest taken care of have these basic things done let me actually show you what developer onboarding looks like so you have a new developer coming into your team who hasn't told which was set up already by somebody who has ensured that everything works and at this point of time you need to come and start coding and here is an issue which somebody has said during the planning meeting that it was just one story point and you're like I just saw in the team I need a date to at least figure out how to write coding and eclipse ID and then I can start looking at code and working on it which means the planning has already been done in that here you have a new member in the team who has assigned a task for one story point but he clearly says that it's not making force to the point because he's doing the team so it means the developer onboarding is hard at that point enterprise or organization would have a new workstation which would be provided by somebody from IT you need to open a bunch of requests and to approve that you need to install a bunch of libraries locally and to do that you don't have to get a program from the manager they're not supposed to install any third party library in there there's going to be endless controls on that so it means it gets really hard to get started and if you're from a company who love to freedom from your previous company you're going to hate it if you have to open three service requests to be able to try out a new library locally so it means this is where a developer workspace in a sandbox environment comes handy you don't have to worry about your enterprise environment because whatever happens is going to happen inside that sandbox nothing outside which means all these workspace which you saw they actually are inside the container which means something goes wrong you just kill the container and you just move on with it nobody else gets affected this is something which I know as developers you're going to open a bunch of requests to get a new VM where all you need to do is set it up and share the world with somebody and that's pretty annoying because you're not in rocket science you're just going to deploy a Java application and share it with some other guy that's it and for that you've got to think about it so I think that you need self-serve with API driven ticketless code managed infrastructure on demand which means if you want it you should be able to get it yourself without having to talk to somebody it should be API driven which means there should be somebody who is responding to a ticket to take care of your request that has to be an API which has taken care of other boundaries beyond which you cannot go which should be servicing your request which means 80% of all developers should be taking care of already and the need of order management means I might want a VM I might ask for a VM which probably ETAB 80% of the CPU of the host machine which is sitting and that is why you have somebody coming and approve that request before you are given that you need to ensure the software does that for you not a human who has to take care of 100 requests per day should be doing that for you and you need to get infrastructure on demand which means you should be told no you cannot get it today because we are still getting a new ASXI server that's just not happening what happens in the end which means the developer does write code with all the trouble of getting a new getting his approvals getting his local environment set up and then gives a code to ops and we can also call devops and that person has even the reason that devops are supposed to work together but effectively you have a code somewhere you have a deployment script somewhere you have a pocket script somewhere and somebody in devops would actually have to take the code and deploy it you know the previous situation where the devops can come back to you telling you know what my puppets scripts are working perfectly fine till you join the company and now with your instance it doesn't work anymore which means the developer lost some ownership of his code service already where somebody else is telling you know what this does not work I am sure this was going to work for you locally but how do you really test the whole thing on a VM why do we do that what kind of stuff do we do right we actually test all the deployment itself on a traditional one so which is why you need to use something like cloud workspace so when I say cloud workspace don't get me wrong I am not trying to pull you into using web technologies by running a local machine everything you see here at the cloud workspace what it means is it wants some open shift which means if you can run an open shift running locally you can have the same workspace running locally in your laptop in your network agencies which you don't like so if I try to get out the demo before my time goes out so this part of the demo is actually showing how a developer's typical day in office should be if you are choosing so not spending too much time setting up things and getting approval of stuff so this is my full-fledged idea which I was just talking about a few minutes back so what I am going to try to do is actually push to master never try this at all but after going to master I am going to show you how a build can be triggered and the problem is going to happen right away the whole idea of the workspace is to ensure we stick to the promised land off every change to master should be deployed and that should be part of the day zero process which we mentioned some time back so I just made some code changes then I flip over to the next file to actually go in up in a test because like I said my code changes without a test should not even entertain and the reason that is the stress test because the build would fail without that because the build does check that tests are run every time to make a code change so I go all the geeky stuff and then to change my code this is basically a strict change and I try to directly push to master I am going to create a PR to master a remote and I do a bunch of clickings and on the bottom right I see a branch pushed origin and I quickly head over to the code base here to check when even the last update was 26 minutes ago then I refresh it 18 seconds ago which means I didn't manage to do a comment from within my web id and I need to ensure that this does get deployed and now as soon as it committed it should actually go through running again which means even though the code is in master it does not necessarily mean it is going to get deployed because it is wrong to actually apply a code which you haven't tested against your own tests and if you have been tested our job is going to work for you which means you plan together a sub feature in two weeks and after the sub feature is done the good test is going to a next environment or production ensuring that nothing is broken and also ensuring that what I want to update right now and it committed to right now is actually released it should usually not have to wait for somebody else to open your web if you have a QD team within your teams just ensure they spend all the time on automating their tests which means they should never be a worker or they should never come in the way to you only to a developer to promote code to the next environment that should never just happen right so let's try to build and let's see where this goes yep looks like the first stage has started the build release is happening in there so in the meantime we are back it checks out the code it ensures that it is mergeable in this case it is push to master there is a question of being mergeable it tries to run a test and it is doing so it will try to figure out if you do have the resources to be able to run the test so it is doing all that taking a while in there and then it is going to try to take it to the next environment called stage and then the next environment called run and gradually there should be a problem in there let's have a look let's check the logs we are interested in tests let's see if they have show ups of it like you can see in there the tests are going to run now and return to the stage and start coding again yep my tests are fast it looks like it has to deploy the stage right now which means it's got to deploy to stage after entering your tests are fine and now wait for me to verify that my ADI is working fine the tiny button in there and ensure that the ADI works but part of that let me explain what is really happening in there so what it's doing right now is on OpenShift it's trying to do a rolling deployment which means it doesn't take out the container which was running which means it's trying to deploy something and it didn't work while it was being brought up it doesn't come playing it just sits back and forgets about it and lets what was working keep on which means right now it begins it transition from version 1 to version 2 without bringing down the first one to your second one result which means you just did a zero downtime deployment on a staging environment to ensure that you don't have to just because the developer made a mistake in his code it should not cause a downtime for your customers you should still have your processes and machinery in place to ensure that things still work so in this case good news for us we could actually join the deployment in the next stages it's going to do the same thing for my next environment as well so having said that we took you to a journey from setting up a new codebase from the scratch and showing you that you can have systems in place which automate the Monday task of setting up your webhooks your build triggers your deployment circuits your deployment process etc you can automate all that if you do that you can ensure that every day your developers are doing every day and trying to push code every day to different environments if your processes and tech is in the right place then you should be able to deploy code to production every day and be true to your channel