 Okay, we're gonna start our next talk, middleware gate checks. Thanks everyone for joining us here in the systems engineering and hardware track. And we hope you find the talk educational. I'm going to start it now. Hello everyone, hope all of you are doing good. It's my honor to have you all here today to listen to my talk. Before moving forward with my talk, let me first introduce myself. My name is Anirisha. Currently I'm pursuing my master's in computer science program from Indiana University Bloomington. This summer, I got an opportunity to work with Red Hat as an DevOps intern with continuous productization team and under middleware productization team on Gates Initiative. My today's talk is based on Gates Initiative. As I'm emphasizing on Gates Initiative, so you all might be wondering what exactly are these gates? Let me give you a very brief walkthrough of what are these gate checks and why and when are they required to be applied on the middleware products? What are gates? Productization core team gates are basically collection of all checks that need to be applied either before, during or after the productization process in order to verify that all the Red Hat policies, requirements and standards are in compliance. Hence, any middleware product have a minimum set of requirements that need to be satisfied before any customer facing release. This minimum set of requirements are nothing but gate checks. The gate checks have been created from a checklist of verifications and they are designed to assist the release process of any new product by utilizing some standard tools and processes. PCT, that is productization core team acts as a central service and it is responsible for enforcing such gates. Such gates are applied to all the middleware products and they are mandatory to prevent Red Hat from being vulnerable to either legal actions, damage to reputation, loss of business or government sanctions. Hence, these gates need to be run at least once before any customer facing release but it is helpful to run them as early as possible in the release process as they help in early identification of problems. Now, why are they used? They are used to make sure that the checks continue to happen and guarantee not only compliance with Red Hat release policies and standards but also to see that a uniform set of checks is applied across all the products. All the product gate checks are documented in a single place and problems are not at all forgotten and a proper plan is put in place to resolve them. Also, the check that customers get quality software and their experience is not at all compromised. Workflume, these gates have been divided into three main categories. First is gates on the code and deliverables, then comes gates on the infrastructure and then comes gates on Red Hat requirements. As the name suggests, gates on the code and deliverables define the checks that have to be done on the source code and the deliverables and the characteristics that the code must comply to. Different and specialized checks can be applied depending on the underlying technology. Gates on infrastructure define the characteristics that the infrastructure involved in the build and distribution process must comply to. These checks ensure that the bills are done in proper Red Hat internal certified systems such as BRU, OSBS, PNC, et cetera, and that the delivery is done via a proper Red Hat distribution channel. Gates on Red Hat requirements define the additional checks that have to be done in the overall build and distribution process, which may include general and strategic Red Hat policies. Workflow diagram. This diagram depicts the working scenario of gate checks implementation. There are different Jenkins pipeline and jobs set up for the execution of these gates, which are scheduled to run the appropriate check for that product and produce JUnit report. This JUnit report are further stored in results to be and the status of the gate checks can be displayed on dashboard. So as I said, they provide dashboard which shows the exact state of the checks and which can be monitored by all the groups. This allows everyone to see the status of products which are not following due diligence. The gates pipeline generate JUnit report which is further stored in results to be. This report is then converted into appropriate JSON message format to publish on UMB, which are then retrieved by results to be updated microservice and then put into results to be. This is the snapshot of one of the gates pipeline execution. It shows the successful execution of the gates pipeline, which means that all the gate checks are passing for that particular product. Okay, so after the completion of the pipeline build, we can go to the test result analyzer to analyze the execution result. This screenshot shows all the different gates checks which are either passing, failing, or skip for that particular build. So now the test result analyzer also shows the build details for that product in a graphical manner. That is it shows the percentage of test cases which are passing, the percentage of test cases which are failing, and the percentage of test cases which are skipped. So as we can see from this snapshot that four test cases are failing. So then the question arises, what happens if any of the test case fail? So here comes a picture exception. If any of the gate checks fail for certain product before it's customer facing release, then it is considered as an exception. It becomes a concern from legal perspective and the team needs to file an exception and store it in Vault. They also needs to be worked upon and result before next customer release. The Vault results can also be stored in Results DB for better analysis and auditing using exception pipeline. Current status. So currently these gates are carried out manually. In the manual execution, it asks the user to explicitly mention whether the particular test case is passing or failing for their product. Based on the user input, the test cases will run producing the results. So currently, product team needs to run the checks with their own solution, existing infrastructure, and by answering a list of questions related to those checks. Now, our team is focusing on automating this gates and integrating it with C pass that is continuous productization as a service. This summer I helped the team in automating one of the gate checks and also automating the process of releasing a new version of the gates pipeline. Automated gates are planned to receive URL to its configuration file as an input parameter. This configuration files are nothing but files containing some metadata needed to run the gate. This are certain links and documentation to help you know more about our team and our work. This was it from my side. Lastly, I would like to thank my entire CP team and middleware protocol team for providing me such a nice experience and special thanks to the P&D team for giving me an opportunity to present my talk in front of you all. Thanks to all of you for listening to my talk. If you have any questions, I'd be happy to discuss them. Thank you. Thank you very much, Neri. That was an excellent presentation. And come join us on video. And there you are. Hi. Hi, you have perfect timing. So excellent talk and very important subject. Thank you. I would be happy if someone had a question. I would be happy to discuss them. Would anyone like to ask Neri any questions? We definitely have folks in the channel. Say, Neri, is there anything else you'd like to add or any comments you'd like to make? I would just like to tell that my entire summer experience was wonderful. I got to learn a lot of things and each and every one was very helpful and supportive. So thank you very much. Absolutely. Well, we're glad to have you. I'm sorry you had to join us during the summer of COVID, but we're glad to have you work with us. Okay, anybody questions? Okay, well, if we don't have any questions, then thank you very much, Neri. Thank you. Thank you all. Okay, have a good evening. You too. That was our last talk for this afternoon. That was middleware gate checks by Neri Shaw. It's a very important presentation and it's very important to make sure that content doesn't go to where you don't expect it to. So it's a very important part of the middleware portfolio and the sort of pipelines are definitely very interesting. So thanks everyone who's been watching. I appreciate your time and I hope you got something good out of your attendance at the conference today.