Enterprise DevOps Series: Mainframe Test Automation

good morning good afternoon or good evening depending on where you are in the world my name is julio godinez and welcome to today's devops.com webinar enterprise devops series mainframe test automation brought to you by broadcom we have a great webinar for you today but before we get started i need to go through some housekeeping announcements today's event is being recorded so if you miss any part of the webinar you will be able to watch it again we will be sending out a link to access the webinar on demand or you can visit devops.com webinars and it will be available for you as well we are taking questions from the audience throughout the presentation use your webinar interface to submit questions into the q a section and we will try to get as to as many as possible at the end finally stick around until the end because we are doing a drawing for 4 25 amazon gift cards so stay tuned to see if you're a winner joining me today is peter vakula testing lead at broadcom i'm not going to put myself on mute turn off my camera and let you get to it thank you julio so good morning good afternoon good evening and thank you thank you so much for joining us today for the next session in our enterprise devops series today's topic is mainframe test automation ibm mainframes are the backbone computing power of most large enterprises and we will focus primarily on this platform when it comes to test automation in today's today's chat i'm pedro watson i'm product manager and testing lead here at broadcom and i'll walk you through this topic today what's on our agenda today so we'll start light with the general understanding of testing and test automation and how it really relates to the mainframe and mainframe platform state of mainframe devops is something we will look next because the devops on mainframes has evolved significantly in the in the past decade but we still do see some some areas for improvement here and there so we'll we'll take a look at the at the current state in there agile transformation will be our next stop and agile transformation was one of the reasons for the significant devops evolution and we'll take a look at why testing and test automation is lagging behind specifically on mainframe and what we might do about it then i'll share with you um our journey we took with our partner customers in understanding their testing needs and of course where we landed in terms of how to enable those testing needs closer to the end uh we will take a look at some sample test cases that we have here for you and i'll ask um arnel who will present this uh for you he's our one of our partner customers so hold tight and let's jump into it so first some some general general understanding of what testing test automation is and how people are perceiving that so if you look at the very first statement and then i think you would agree with it everyone understands testing is important right testing ensures you deliver quality code no one wants to deliver a buggy code and there is a customer satisfaction or even experience a production down situation you for sure don't want to be in that situation so generally everyone understands that without testing you cannot deliver quality code and then you might put yourself in danger by delivering untested codes if you look at the second statement then i think this is this is really coming and it's dictated by a common sensory everyone understands automation of testing is important if you automate your testing then of course you free up your engineering time to invest into delivering some new business value rather spending time uh repeatedly doing manual testing right so you would you would understand commonly that if you have if you take your testing put the effort into automating it then you do not need to really go and redo that again you do not need to go through the manual effort and it will run automatically and this for sure free you up for some of the new initiatives that your my business might be dictating you to do so and so yet most of the mainframe testing is done manually so despite everyone understand testing and test automation needs only very little testing is automated on the mainframe throughout my customer interactions i learned that only about like 10 of the testing is automated and and before before before you you start um shouting out different different numbers what i mean by the by the testing automation is that i mean like fully automated from from the testing itself to interpreting the results in a fully automated fashion as part of your software delivery pipeline so why only so little is automated on the mainframe and i think it's a it's a combination it's a there are there are several factors coming from historical cultural as well as technical reasons and as part as part of uh looking at those we'll we'll take a look at some of the aspects of why this is when we will be talking later on on the agile transformation in a moment okay now i want to take a look at some outcomes of a recent study the state of mainframe devops and i want to highlight some of the some of the concluded things throughout that and that study and one of the conclusion that was that was driven there by by a survey was that the automated testing tools have contributed the most to mainframe development improvements so the potential of introducing fully automated testing drives a significant devops improvement right so just stop and think about it um 40 percent of the respondents said that these test automation tools have had very big impacts on improving their overall devops and i think you should you should keep that in mind we're assessing uh the the return on investments and throughout different different initiatives in your um devops devops initiatives so the the automated testing tools and the focus on automated testing might yield a significant return on investment and i think that's something that you should you should keep in mind another key takeaway for myself there was that and and i want to share this with you is um is a statement from from a director at a large financial institution that says we knew that if we didn't include mainframes this critical part of our infrastructure in the devops process then there would be consequences if mainframes are a part of the process you just can't ignore them and develop separately so if you read a little bit into that what it really means is that if mainframe is part of your devops you really cannot leave it apart simply because it would eventually have impacts and those impacts might be and i've seen those might be in terms of a bottlenecks right if you treat mainframe as an island and if you don't include it into your overall enterprise devops processes then this would probably run into into some um some bottlenecks when when developing your full stack application because your full stack applications cover not not only the distributed parts non-mainframe parts but also the mainframe and if if the mainframe develop the development is not synced with uh with those processes then you put in yourself into danger and you will not be probably as agile as you can be so keep keep in mind that the the mainframe should be treated as yet another platform and not as something that is that is a stranger on an island okay so how do we bri bring about the test automation culture so previously i've indicated that there are still some some improvements when it comes to test automation uh test automation uh specifically on the mainframe but let's take a look at agile transformation and what it really meant so the agile transformation has happened throughout the industry and if you if you remember from from the history not that distant the prevalent methodology to develop a software was really a waterfall right so you would do the planning for the whole application cycle um after that you would spend you would spend years developing that and only after after that period you would you would release that this proved to be kind of inefficient when providing the new value to your customers to your users so that's why the agile transformation happened and this also impacted the mainframe as well so even on mainframe now you see that the agile scrum teams are being prevalent and all the agile teams also those on on mainframe are empowered to be self-managed and take on full responsibility of the teams and products so the teams are being asked to really take the life cycle of their product from the beginning to the end but still on the mainframe that is even today a little bit seen as a siloed entity even within the mainframe are some siloed uh siloed um parts so one of the one of the siloed part here might be the testing because the qa testing is not always part of the agile team and when we work with our partner customers and this particle instance a top five retail bank in the us they've concluded that the ideal way to bring test automation to the mainframe is to shift it left into the local development and ci cd processes enabling the agile scrum teams to create the tests so even though you do see that the agile transformation has happened the teams are being asked to take responsibility for the responsibility for them for the application well-being there are still some siloed entities when it comes to quality assurance and and the development team is not fully responsible for the uh for the product quality and the recommendation is really shift left and the responsibility directly to the development teams and this would be probably about like doing some cultural shift when it comes to test creation because when the when the development or the scrum team develops the application they are for sure doing um doing testing they do not like just code it and throw it away they will for sure do testing they'll start with unit testing they might do some initial functional testing maybe even even look at some performance testing but then the most part of the quality assurance is being done outside of the team as what we've learned and really empowering the agile teams to own the responsibility for not only creating the tests but also making sure that these stats are being being leveraged at all levels of your service delivery life cycle that's probably the thing that we want to inform and we want to kick-start the test automation culture change so empowering these teams to own the responsibility of creating test states at tests at all levels that can be reused at any level of service delivery lifecycle is key to kickstarter test automation culture change if you now would embrace the uh the shift lefting of the quality assurance testing closerly to the agile team where the development happens and be part of the team then there might be an obvious question that you might want to ask yourself straight away right who writes the automated tests within the team should it be developer should it be someone who represents their quality analyst if it is part of the team is it someone who's very focused on automating the test cases someone like software development engineering tests and really if you if you look what agile team means is that i think that the push there is for anyone from the team to be able to pick anything so when we work with our partner customer bank and they feel strongly that it is important not to be boxed into dedicated roles for this in agile anyone in the team who can contribute to the team's uh course should have the opportunity to do so right so if a developer um is able to write the test cases and help with automating that he should be empowered to do so if there is a quality analyst who will be able to help with uh with the test cases themselves and then a software delivery engineer and test that will help with automating those they should collaborate in uh together and to build those test cases and own the automation from the beginning it should be the responsibility of the team so we should empower the teams to own them on the test cases and empowerment leads to responsibility and responsibility leads to ownership and also who doesn't want the quality to be owned as early as possible in the service delivery lifecycle okay now let me let me share um the broadcom's approach to help with uh testing shift left the one that i've just mentioned about um moving it from the quality assurance and make it part of the development team but before before we go to some answers uh let me share the journey with you that we took with our partner customers so essentially where we started at the very beginning was we wanted to identify the type of testing that are most critical took the longest and required some specialized knowledge that that was something we wanted to learn at the beginning because we thought that this would be something we can then find some uh reasonable use cases and help with that how we did that so we did the series of exercises we we did for example as is mapping so we looked at the current flow of the application development we worked closely with our partner customers on identifying the different stages what are the pain points or what are the responsibilities how the responsibilities are handed over different different and different stages and based on this ss mapping we were able to harvest and crystallize some some use cases of course we we looked at the most uh most prevalent and most pressing use cases and we we wanted to use these use cases to go from the esses to something that would be the 2b scenario and for that we started to building the requirements for those use cases and those requirements then eventually led us to the potential to be scenario that i'll be sharing in a moment so if i go back to our initial initial ask or initial intent of identifying that the types of the testing who would be the most critical took the longest and would require specialized knowledge the answer were pretty straightforward right so we got the answer that uh it's it's the testing after the application change made it past the development phase so we just confirmed what i what i shared with you on the previous slide is that there is there is a quality quality assurance beyond the development team um that is that is being on there and it usually takes a combination of an application subject matter expert probably business analyst or product owner and the quality engineer they need to work together they need to identify set or subset of test cases that needs to be run for the specific application change in order uh to get an approval for promoting this application change into production and this was done uh beyond beyond the development team and that's why we are thinking of shift lifting this closer to the uh to the development and the and the type of testing that has been done in these stages was primarily functional testing so let me let me also just share some some use cases that um that we boil down into one was validate changes in a data set after batch application execution it might it might sound pretty straightforward similarly the the second one here on the slide preserved as data integrity between test runs again on on distributed platforms you might take this as a granted but throughout the different terminology and slightly different different approach to mainframe batch execution and then validate into this data it was necessary to start looking into the use cases and how those um we would want to tackle so now since we since we have this uh this identified and we start looking into the uh requirements gathering then we started to look into into the answer but before before i go really to the uh to the answer uh i need to i need to uh give you a little bit a little bit introduction to to zoe because zoe is the enabler in here not everyone uh is probably um familiar with zoe but i would hope that most of you are already what zoe zoe is an open mainframe project it's a modern open source interface for the mainframe and it really opens up mainframe securely to the enterprise devops um in general right so your existing devops tool chain can be also used together with mainframe through uh the means of opening up the uh the mainframe securely and those uh those interfaces are command line interface and those are apis those apis can be and can be aggregated through api mediation layer of course as part of zoe you would you would find an id extensions for visual studio code there is also an web ui and a software development kit or sdks that enables you to call the mainframe actions directly through your tool chain that you are already leveraging as part of your enterprise devops what's what's what's more more important than appearing around zoe is is that it builds community around them around mainframe devops and it kind of makes mainframe exciting exciting for uh some of the uh folks younger in their uh or or early in their careers what's really about zoe it's it's really open uh first open source project based on z os and the initial contributors were from broadcom ibm and rockets you do see some statistics in here just not worthy mention is that most of the committers now are coming from broadcom and i think broadcom now owns most of the zoe conformance uh badges that conform with with our um cli plugins or rest apis that we do confirm with zoe criteria hopefully this gives you some some idea of what zoe is because zoe approach and and zoe itself is really enabler of what i will be talking on the next slide when it comes to the answer to broadcom's approach to help with testing shift left so as i mentioned we work with our partner partner customers and we wanted we wanted to take a look whether the open approach to mainframe and devops would also also play along with test automation the the motivation was simple right we we are pretty successful with the open end approach to mainframe and the devops practices so how we can leverage that also for mainframe test test automation so again we were working with our with our partner customers especially those who already embraced the zoe approach uh to opening up the mainframe securely and we identified a set of apis-based services that would enable the use of popular frameworks test frameworks and scripting languages that all that are already prevalent in the world of test automation on the mainframe staying true to our motto of making mainframe just yet just yet another platform uh we set uh out and started creating api so if you if you look uh look at the picture in here really is the testing apis that are bringing bringing the value those testing apis are are built on the long-standing mainframe security and the resources that you would be accessing those are the testing tasks that you would want to incorporate into your automated testing suit so here we started with the initial subsystem for batch basic data set style but also sequential cluster data vsams we're further looking into transactions and databases uh subsystems as well and all this is uh powered by the idea and powered by um by zoe and it's the test automation developer choice of testing framework because we're not dictating you what you should be what coding language or what testing framework you should be using it's it's really up to you because those testing apis can be leveraged in in any of those so just to repeat here um staying through to our motor we really want to make sure that uh also the mainframe application testing opened up mainframe as yet another platform in the hybrid ecosystem and this all led us to start building so-called test for z so test test for z uh is is the service and set of apis that we initially we initially built and released just recently it's built on the platform it's secure with the mainframe um mainframe security and our tests for the apis are conformant with the uh with zoe zoe conformant criterias and here you are looking looking at the swagger swagger api documentation um describing the initial the initial end points that you can use as the testing task as part of your test cases so compare to data sets search for specific strings within your data sets to filter on using um copybooks or you can you can prevent prevent your your test data through snapshot means or if you would want to tackle some of the hk scenarios for your testing you might be doing some small updates and your test data just to drive slightly different um different test cases so this is this is where where test4z was built these are the apis and this is this is the main uh main power of the approach that we are suggesting here but when working with our partner customers um they do understand that the apis are the foundational uh part of um of this approach uh but our um partner customers were really interested in more guided approach to get started and so so we we looked and we saw that test scenarios and samples were really needed so what we what we did we've built a sample test case repository publicly available on github.com that illustrates some of the use cases and are providing um the sample test cases that you can you can look at right now and see uh see how we did that it's leveraging just testing framework uh it's a it's a javascript based testing framework for starter it's easier to read very well documented so that's something that you can you can take a look and and see for yourself right now of course we um with with our like um open open up mainframe approach we had some good successes with providing so-called sdks for calling the rest api rather than um giving giving uh the the users uh only means of like uh calling the rest apis directly so what we did for for the samples that we are providing we also build a node.js library that is also publicly available and instead of calling rest apis directly which by all means you can you can still you can still do your you're free to do that but we are also providing this convenient way of calling this funk function in within the node.js library to get you the functionality instead of really building building the rest api string on your own so now i've i've talked about i've talked about the sample uh sample test cases and i think uh what i i wanted to hear is i want to i want to show you a walkthrough of of the sample library and for that i've asked arnold who's engineering lead at bank of new zealand uh to share share share his experience with test4z with you arnold is one of our partner customer in this one and we'll we'll do it uh double virtually here so arnold recorded for us a snapshot video so i know i'm going to play it now for you hey everyone this is farnell engineering lead at the bank of new zealand we're delighted to be able to leverage enterprise testing frameworks for mainframe with test4z it enables us to automate more of our mainframe query process while taking advantage of existing in-house expertise and align them with enterprise id standards test4z provides mainframe testing capabilities through rest apis let's explore test4z sample test case library with tests written in adjust javascript testing framework what we're looking at now is a github project and the test4c sample readme.md file provides a quick overview of the service it further describes steps needed to set up your development environment so you can easily run the sample test cases the sample library comes not only with the sample test cases but also with sample batch jobs and test data all this can be easily deployed to your mainframe through an automation shell script let's go ahead and clone the test for the sample get a project for that we're going to use a freely available ide visual studio code should see the code clone the repository there you go so we've just cloned the repository and now let's let's look at the structure by the way we can also preview the readme.md file directly from visual studio so the test for z project contains a source folder with two subfolders setup files and tests the setup file subfolder contains a shell script and files that are used to set up the needed mainframe datasets including jcls and test data while the test subfolder contains suggest testing framework test case samples those are organized in respect to the test for ze service endpoints so let's now explore the compare test case structure what you see here is a test case with an ingest the describe block introduces the whole test suite and individual test cases are introduced by the test keyword for this particular example we have only one test case you can also notice the setup before all and tear down after each methods are executed before and after each test case let's now look at the test case itself the sample illustrates a situation where you want to compare a data data set with a before and after batch job execution state so using the test for z service the snapshot data set is created then the batch job itself is submitted and executed so for each of these actions you assert the expected outcome using the expect keyword if the job is successful then you compare the snapshot with the original data set using test for z service compare and further on using expect statements you would assert the expected results and that's that a sample test case that i can grab execute in my environment and then use it as a guide to create test cases for my own testing scenarios really looking forward to expanding our use of test4z as our api portfolio scope expands to include additional maintenance technologies thank you for watching see you again soon cool great thank you very much arnold so you you had a chance to to see how the structure of the uh of the sample test case looks like and as mentioned previously this has been um this is this has been done in conjunction in conjunction with our orbit with the help of our partner customers just to make sure that the onboarding of the test for this service is as sea as easy as a cms as possible so hopefully hopefully you do see that and as mentioned those are publicly available so at least you can go there and check for yourself okay now let me let me give you some some additional additional quotes uh from uh working with our partner customers um and and those i picked those two particles because i think it illustrates um some of some of the key aspects behind test4z so devops product on devops product owner uh said that it might it might take a couple of hours to learn a new test framework but we'd use any framework that offers the mainframe testing functions uh we need and i think um it's uh it illustrates um that um through some of the um core major uh mainframe teams there might be a little unwillingness of experiment with new testing frameworks or different coding languages but essentially if you do have a need and if you do have a priority in automating your test cases because you you you see the uh the return on investment or you do have a specific need for that then it should not matter what uh what is that what is the two it's just yet another tool you will learn and you will use it and this is and this is um how it should really be uh one of the one of the other quotes and that this coming from a software engineer who has very strong non-mainframe background and i and i think it uh kind of underlines the uh the main main additional value of test4z and he stated i like that it uses an existing open testing framework which makes the mainframe testing tools more like distributed so you should you should see the the additional value immediately right so if the mainframe testing looks similarly as you're distributed then there are really no differences and you are treating mainframe as yet another platform in your hybrid uh enterprise ecosystem and that's that's where we should be all striving for with that i have some pointers for you uh that you might you might want to explore further if this has been um interesting to you and i think that the the very first thing that if you feel and if you if you want to look closer at the approach that broadcom is taking with the source then please ask your broadcom representative about bright side uh what is bright side uh bright side is broadca broadcom's enterprise support offering and this uh support offering uh includes also um tests for uh eligibility for test for z so if you if you would ask for bright side this would this would also drive the conversation towards test 4c so please go and ask what you can do right now is that you can you can check the github.com samples right away so go go under the broadcom mfd organization and the repository is simply called s4z check it out uh you can you can review those different um use cases we've tackled there the the samples are illustrating illustrating the flow and you should get a good idea of how this works if you if you would want to learn a little bit more details than what i've shared with you today then my colleague pam diesen she just recently published a medium.com block on the modern dash mainframe um [Music] category and so you can you can go there and and read it read it on your on your own it will give you additional additional more details um what i would from my own experience recommend is uh so-called design thinking workshop and you can you can ask for uh the designs uh thinking workshop with broadcom specifically on testing why i would personally recommend this one to you is um that it really gives you the opportunity to uh like peer with uh with us uh with uh looking at your at your pain points at your priorities uh from uh from little distance and trying to look at it out of the box and we'll help you with that in the in the design thinking workshops and it is it is very surprising when uh customers or the participant or of a design thinking workshops are talking about about the elephant in the room without really seeing in seeing him and then when they realize that the elephant is there um it is it is the it is the biggest benefit of these workshops that i have been part of and and i can only recommend it so you can go to this and to this url and and request a design thinking workshop and i really recommend it to you it's fun one last pointer here if you if you are interested in hearing more next week there is a devops enterprise summit and my colleagues will be talking in a session called modern test automation from cloud to mainframe this might be this might be very uh very interesting to you as well and i encourage you to to look at the devops enterprise summit and to see more that's that thank you very much um i'll uh i'll share here also my email address with you if you would have any follow up questions or if you would want to just get in touch drop me a message my email address is better.watsula broadcom.com and with that i'll i'll take any questions that there might be in there let's see okay you can you can post your uh your questions into the q a tab and then i can start looking through those i see i'm just looking through the chat and in in the chat you uh we've we've pinned also the the three three three url pointers so you can you can grab those and look at those directly for your convenience so let's take a look at some of the questions okay how can i try test for z so the the easiest what you can do right now you can you can check the uh the open github and github project it will get you an idea on those use cases as i've already mentioned you'll see the different actions and how the test 4c service is being called and this might be the the initial initial uh try of test for the experience but going going a little bit a little bit uh beyond that what um i might uh recommend is that if you if you don't own the uh the bright side support offering that includes the test for the eligibility and then you might get touching we get touching with me and what we can do we can we can do a workshop specifically dedicated to testing and test for z and there we will provide you with uh with the workshop environments and through like structured design structured workshop exercises you might get hands on on the test for znc for yourself so this this might be a very good opportunity for you thank you for the question yes there is a there is a question on pricing is there any pricing for using test4z and there as i've mentioned this is part of the enterprise support offering for zoe coming from bright side and so you would you would what you would need to talk with your um with your broadcom customer representative to talk about about the bright side support offering another question coming in our mainframe team does not have experience with javascript what are your suggestions here so i've talked about about the sample library that sample library is using uh just javascript testing framework and the node.js package is is also javascript so i i do see i do see um um that you might you might feel a little bit uh a little bit off if if you don't uh um use javascript very often but really what i would recommend here is pick another coding language pick another testing framework the the whole and main idea of test4z is that it's open uh through the rest apis and so as long as you can call those rest apis through that and through that language then you can leverage this force and is it is it uh java is it python it's it's really up to you but i can i can tell you if in your team nowadays it's at least someone and i i bet that there is someone like that who would be willing to skill up when it comes to new technology then it's nothing easier than just to like pick pick one uh give and give that person the freedom of learn upskill and this would probably even help with um transforming the cultural shift of uh having greater development teams owning the not only um not only the development but also also the testing and quality of the overall product okay oh thank you very much for this question and i forgot that mention is there a prize for design thinking workshop there's none so you can ask for it freely i will be more than happy to facilitate for you and as i mentioned the design thinking workshops and those that i've been part of were not only fun but those who are really driving driving some some good insights good takeaways and then action items that have been previously that have been and that have been then implemented so i would i would recommend you there is no price associated with this design thinking workshop at this point another question um are you working on a tool that is capable of reading the copybooks to help the generation of the test case so we do leverage copy books especially google copy books when operating with the data so it would it would uh it would kind of make appealing to start start generating those and those test cases out of the copybook but i think we would be then going more into into unit testing and quite frankly i think it's still it still requires someone who would do the initial quality analysis right because um you can you can start putting in um let's say reasonable reasonable testing data but unless someone does a proper quality analysis you will not be sure that you are really touching all the aspects of the of the application so for sure something uh something that we might keep in mind but at this point we we do not have it on our radar okay one more question i see in here how do you automate testing of kicks transactions um yeah thank you thank you very much for this question um i'll i'll lead it with uh sharing with you some um outcomes of research that we did related to kicks testing so number one surprisingly most of the kicks testing is done manually number two uh the means to do the testing order or the method to do the testing is through 3270 and terminal emulator screens there is a desire to automate testing for sure but the general belief is that the automation should simply automate what the human tester is doing um this this might this might lead you into into a realm of so-called robotic process automation rpa and it it sounds it sounds really uh really interesting um and uh it might be it might be a way to go but i myself haven't haven't drive conclusions on that yet on the on the specific uh testing for kicks test for z currently doesn't facilitate kicks test automation uh but we are looking into it so i myself still have many questions around the kicks testing and how to help with that and since you've asked this question um i would i would expect that there is some need behind that so what i'll ask you here please drop me a message and actually anyone anyone here on the call if you um if you do have a need for kix test automation or if you are looking into that drop me a message because i would want to chat on that we can we can do it informally through one-on-one chats or we can even empower a more structured way through the design thinking workshops as i've introduced in here because eventually uh there are there are benefits not only for for myself to extend the knowledge of how testing is is being done but also for you um to to learn from what we know and also you might able to help us to shape this for z to suit your own needs and i think it might be it might be very interesting so please um if you are um dealing or looking into automating kix test applications please drop me a message okay i don't see any other question coming in so i'll pause for a moment if there are any other questions please type them in the in the qra chat okay i don't i don't see any anything else coming up so thank you thank you very much for for your interest for your questions um and as usual if uh if anything else will pop up just drop me a message will you okay thank you very much everyone um just as a reminder that this uh webinar has been uh made uh has been recorded and will be made available to you uh just look out on the devops.com website and it'll be there for you and um and now for our uh four amazon gift card winners uh our first winner today is dawn s congratulations don our second winner today is dirk t our third winner is dora s and our last winner is von m so congratulations to all our winners we'll be reaching out to you via email with instructions for claiming your amazon gift card so please check your inbox and if you don't see it there please check your spam folder uh thanks again peter for an excellent webinar and thanks again to the audience for joining us today this is julia godinez signing off until next time be well you

Channel: DevOpsTV

Views: 70

Rating: 3 out of 5

Keywords: devops.com, devops, devsecops, continuous delivery, microservices, containers, devopstv

Id: QL-blX_epwE

Length: 48min 21sec (2901 seconds)

Published: Tue Sep 28 2021