 Okay, so the next talk is pretty interesting as we have got two speakers on board, Kunal and Sanchit, and their topic is ticketing plus, oh, sorry, okay, ticketing plus deployment automation using Python Django. Okay, before starting their talk, we have an announcement. This is a Kindle that Prasanjit left in the knock. Yes, it is Prasanjit only. So somebody who knows Prasanjit, please inform him that his Kindle is with or lying in the network operation center. Somebody knows Prasanjit, hello. Nobody knows Prasanjit? Poor Prasanjit, lost a Kindle. Okay, so a tweet using Prasanjit, your Kindle has been found, yo. All right, good afternoon, everyone. I am Kunal Agarwal, and with me, I have Sanchit Bansal. We are from the DevOps team at Make My Trip, and the topic of our presentation is ticketing and deployment automation using Django. So in ticketing, the problem statement that we had was basically all our requests that were taken in the organization for any user ID creations or anything, were all tracked on email. So requests were raised on email to their managers, then it forwarded to the next respective person. And then, since it was all tracked on email, due to the large amount of emails, everything was, you know, the turnaround time when it was large or everything. So to fix that, we created a ticketing tool for it. So the requirement for Django was, since it was a ticketing tool, it required several configuration changes for every specific LOB that we have in Make My Trip. Since there are several type of requests that are created, there might be a deployment request, there might be a user ID creation request. So there are several changes for that. So, and we had API frameworks to hook up to. So Django seemed a great place to start with. Then we had dynamic approval stages. So we don't have fixed assignment stages. Let's say if I raise a request, it goes to a specific person, that does not happen. It might go to a manager of a specific individual. So that's a dynamic stage. Then we had to create a workflow engine because what happened was, since an approval stage was too, we added. So every time, we didn't want to be, making changes in the code itself, we need a flowchart kind of system so that we can make changes in the flowchart and then they get reflected on the UI itself. Then automatic assignment to a respective individual rather than forwarding emails on a dashboard, they can view what all tickets are assigned to them, take action on it and inform the respective request razor. And then since everything was previously tracked on email, so a request would typically go pending for a week or so. So to prevent that, we had an automated mailer setup for a long turnaround time. Let's say if a ticket went pending for more than three days, you wouldn't send a mail back to the person who the ticket was currently assigned to so that there would be less delay in it. So this is what a ticketing dashboard looks like. So we have three sections in it. One is an assigned ticket, one is a claimable tickets and one is a my ticket. So basically there are two types of assignments in this. One would be a specific person assignment, other would be a group assignment. So this is why we had a my tickets and the claimable tickets. Then once you, to create a ticket, you can see we have a form here. So how this form comes up is, basically we have a backend that is activity on which we define flowcharts of the approval stages that needs to go. So as I told you, we don't need to make changes into the code itself. To add a new approval stage, we just modify this flowchart. Add a new approval stage, change the arrows to it and once we deploy this change, it will automatically reflect on the ticketing tool. A new approval stage would be added. Males would automatically be sent to the new approval stage, whatever is changed. Then once a ticket gets assigned to you, you can view all the information that was raised in it. So this is basically a typical workflow engine that was created just to make sure that no code level changes would be required. Any new process that needs to be created, no code level changes again, no code level changes is required. Only a new process needs to be created in a workflow and it automatically gets reflected on your home screen under the raised request and it works fine like so. Taking over from here will be Sanjit on deployment automation. Thank you.