 First of all, I really want to thank you for joining me here. I am Pooja. I work with Moe Engage. A brief about me is not so brief. After years of trying to find out about myself, I figured out one word which explains me Moe is I'm an explorer. I have explored a lot of things. But I'm yet one of you who still feels that I have a lot to explore Moe. In work, I had been a developer, a QA, an automation engineer, and now trying to double with DevOps and take-offs terms. In personal, I am a foodie and sleep lover. But loving yoga makes me in a situation when nobody can find out that these are my hobbies. Coming to the work, I am coming to work. Sorry, I work with Moe Engage. And at work, I try to bridge the gaps between all of my teams. And with that mindset, I lead a team QA and currently actively focusing on building automated systems which can improve the collaboration across the teams and help us build, shape the healthier product. Along with the work, I am an open source lover. With that interest, whichever project I use for my work, I make sure to contribute back to it. My recent contributions can be found in GenKines and automation-related plugins. Coming back to the talk today, I am going to introduce you to one of our special team members. Her name is Alice. And I can see some faces glowing. Sorry for keeping you hopes up. She is a bot. Yes. So we are going to go on a small, crisp ride to meet Alice, starting from why Alice took birth to what all it can do and how a part of it, the ingredients and recipes, how we cook it, followed by the demo and QA at the end. So are you guys with me so far? Alice needs more voices. Yes? All right. So we are going to start with why. I take you to one of our typical release days conversation. So just try to recall your release days to understand it better. It's 9 o'clock in the morning, 10 o'clock you have decided to release it. And all of a sudden, a road blocker comes. So here is one of our team member named Karna, who is coming running. Hey, Draupadi, something is broken. You are about to release. Can you just figure it out? And here is Draupadi, who is one of the QA member, who was super sure last night that it was working. And she's like, no, it cannot be. And she panics and says that, OK, let's try to talk to Bheem, who was the developer of that feature. Bheem, on the other hand, has the general notion because, hey, I God swear, I did not touch this from a year now. How can it be me? Right? And same time, seeing the situation, Krishna, who is a CTO, joins the discussion and says, hey, guys, just settle down. Try to find the buggy commit. And let's revert that commit and move ahead. Now Ajuna has to come and do the dharma. And the dharma is go to the GitHub and try to find out all full requests and find the commits, which was buggy. It is going to take time. A lot of full requests has been merged now. Seeing this, Bhishma Mitama, who is a DevOps, gets the clear confusion like, oh, no, we cannot release now because it's going to be peak hours for customers. So let's just postpone the release. And you know now, this rush draw, being held place, they have to say, no, we cannot postpone. We have planned and we have committed it lines. What do you do? I want to know how many of you feel the same pain, which I just described? Hanks are raising, thinking that bosses are not sitting around. Yeah? Yes? So yeah, same thing happened. And if that happens, what do you feel end up with seeing this situation? What do you call this? Blame game? OK, we don't like to use negative words, but we say that some kind of conflicts, wherein people are not able to move ahead because of so and so whatever reason is. And then that happens to you. What do you want to do immediately? This? And you feel, no, there should be some way. I also felt that. And that's where we figured out what all problem we are seeing are just the symptoms. The problems, the root causes are beneath. And we wanted to really work on the black area, which we see here, the black area, but the problems, which we were not able to figure out till then. And that's where I take you. From now, I'll take you to the problems one by one and the solutions which Alice brings in. But before that, let's understand how a typical code flow happens in our organization to give you a better understanding. So here is our developers who write codes in their own branches and pushes to GitHub. And from there, there is a full request, which goes to the developer branch. From there, there is full request to our test branch. We call it QA in our context. And from there, we decide that this is a code freeze. And QA team will be testing only on this so that no confusion happens. And when everything goes right here, we move it to master and we take the release from here. So what we figured out is the root causes were within this area. This area, which we called, it is a sensitive area. And all the branches within, we call it sensitive branches, the test and master. So we figured out if we could put some kind of way to monitor this, we could resolve those problems. So to look at this problem, again, I went back. The developer inside me told that Beam was right. He did not touch from in here now. Should he leave his current work and check that? Yes, we don't want to lose the productivity. And as a QA, I feel the same. Whoever bug it is, I just want a solution to take it ahead and same as the DevOps. And finally, the automation engine inside me comes out and try to bridge the gaps between all this and say that, hey, this communication problem is also repetitive in nature. It's happening every release. Can we do automation around it? Can we do automation of monitoring this sensitive branches? I take you from here the how part, what are the problems, and how Alice solves it. So for example, the very first problem, the last moment panic attacks comes because of we are somehow taking the unreviewed commits inside the system. And that's where Alice says that, hey, do not let them go inside. So at present scenario, GitHub has launched the approval and review feature of it. But when we started, it was not there. So we started with this. And still it has its own meaning. I'll take you to that in demo section again. So whenever such thing happens, whenever somebody merges the code without the code review, Alice does this. It auto-rewards it immediately informing people. So we are using for communication, we are using Slack. And for code collaboration, we are using GitHub. So we Alice knows and parses and finds out what is wrong and reverts back. Second problem, no quick record. So we saw that that was Arjun who has to go through all the PRs and find out. And it was him all the time. So could we make it more understood by every member in the team? And that's where we decided we'll have a permanent channel for each repository we have. And Alice keeps recording for all the events happening in the sensitive branches. So for us, merge was the sensitive event. And the branches were QA, Dao, and master. So Alice does this. So looking at this, we can come to know if, let's say, I'm a QA engineer and I have to approach if this feature was working two hours back, and it doesn't work anymore now, I do not need to just alert channel, hey, everyone checks this. I have an understanding, OK, these two will request probably I can check, and who is the author, I can actually discuss with them. And it eases up everybody's task in that sense. So whoever has committed within that timeline, they can see and quickly fix this. Next problem, no danger boat. So mistakes are prone to happen. Accident can happen if you don't put the danger boats. And that's where Alice says that, hey, be proactive and put the danger boats. For example, this feature we introduced for DevOps, especially, so we found that there were some machine level, DB level changes which people were doing, and missing, forgetting to inform the DevOps team. And that's where we decided, OK, how to not repeat it. And one of those example is this. So whenever some sensitive files getting touched by someone in one of those sensitive branches, Alice comes and rewards, informs, respect to the DevOps team, hey, this is being changed. So if DevOps has to check that and whatever they want to do, they can do it afterwards. One of those example is this also. So we say that, we will take release only from the QAID branch, not from the any other branch. So Alice does is what, wherever somebody creates a pull request from some other branch, random branch to master, Alice autocrosses it immediately. So we are saving our time of mistakenly merging wrong fias and then reverting the code again. Lack of awareness. So this is one of the one where Alice got more feathers in its hat is Alice says that, hey, people have tendency to forget how to keep reminding them. And that's where it says that keep me posted. So Alice post for multiple things. For example, Alice, the moment you, as a developer, merge some code into some special branch, Alice rewards, hey, you have merged this and so and so and this. Now be nice and just mention it, the release nodes. So it helps QA team to derive the bandwidth when they can release. And others also have the clarity of the things. Next is this. So whenever we are about to release, we want to inform all. This is auto alert Alice sense, hey, we are about to release, especially to tech leads. If something is missing or something they want to add up just before release, they are aware. This is one of very interesting thing. I myself has done this mistake a lot of times. We took release live without J's update and we all know what happens. So it was for five minutes, our UI was not reflected and people are trying to find out what went wrong was just the forgetfulness. So we decided, okay, when there was somebody merges to the release or master branch, Alice immediately thinks, hey, did you fill this checklist? If this checklist is not filled, DevOps doesn't take the release live or whoever the release engineer is. No automated guide. So we were around 20 engineers when I joined Moingate and we exponentially increased to around 40 engineers and telling everybody, educating everybody about the process was becoming tedious task for me and that's where I saw full potential of including automated guide. So bringing the talking bot. So I'll come to the tech inside how we are doing. So you just asked Alice about the system. It knows everything about that system. From static replies to dynamic to giving it a task. For example, hey Alice, give me release notes. It's reverse. Hey Alice, how do I take my patch live? It reverse the instructions. What do you need to do? Hey Alice, dynamic, hey Alice, start my machine. It goes and triggers whoever is responsible to start the machine. Hey Alice, get me the branch name. So if I'm a product manager or somebody else who do not want to go into all details of SSH to machine and finding out what code is being deployed, that's very handy for that person. Alice, it was back. Now coming to the tech behind. It's no magic. It was all here. But what it took me to do it was connect the starts. They will get API, Slack APIs, report APIs and Jenkins. So I really want to appreciate Jenkins community completely because all the ideas I got from there to automate things. And how we did this? So we have GitHub repository and each repository has a webhook mechanism from GitHub wherein whenever you merge a pull request, there is an event triggered. And this event triggers Alice. So there is a full payload of pull request of pull request which Alice parses and says does the particular action, the business logic. Business logic can be pushing back to Slack. Business logic can be talking to, talking bot, Hubot, and Jenkins. So these all are interconnected to do whatever, whoever is best at doing what task. They are just interconnected with the main source code called Alice. So let's have a look, quickly have a look at demo. So for simplicity, I have kept one. Is it visible? No. Okay, now. Somehow not increasing. Someone is operating a laptop. Okay. No, it was a joke. I had a demo recorded. Okay, so coming back. So I have one commit ready and I say this. I create a commit root con, live from root con 17, and I say create pull request. The moment I do, Alice does multiple tasks. Do you see immediately the guideline has come? The respective person has to do. Now people will have conflict. This we can do in the contribution probably with GitHub only. But I'll come to it also why we needed this because for different branches, we wanted to do different checklist. The moment you see that there is a Slack channel for simplicity, I have created a Slack channel to show you. So here is a repo code. It has got the entry. Hey, this is being this in this repo. This is being opened by this, et cetera, et cetera details. And if you see, yeah. So if you see this, I'm sorry. So if you see this, I created a change in the file which has a rule of if the file is changed, product plus one is essential. And whichever, which that rule says that, okay, if this is being merged without the product team approval, this should be either rejected or being informed. So I merge this commit. Let's see what happens in the channel. You see, it says that, hey, Pooja, this is merged without a product plus one. In one go, I got this detail and there is one more entry in the repo code which we saw the common place to track back. It gives the entry, okay, this is being merged. So now Alice has all the trace back. So if a person wants to know what were being merged, they will come to this channel and really channel is especially to inform to take actions if it has to be reverted back or automatically revert back. So you can set the rules or deselect the rules in Alice for that purpose. Now commit to the talking board. Let's talk to Alice. I can ask Alice, I can invite Alice as a user in my Slack channel and I can say that, no, it's not Alice. It's not Alice. Okay, so I can say, hey Alice, how to take my batch live? So if it knows, it rewards. If it doesn't know, it say, I don't know. And hey Alice, you can say, what is branch on my one more for my machine? It goes to the machine. This is a dynamic reply. It goes to the machine and it rewards back. And if you feel that this is too much noise in channel, you can directly talk to Alice. Alice, you can directly ask Alice, hey, hey Alice, when is the next release? These are the dynamic feeder data which one of the QA teams probably gets feed or the release team can feed. And you can go more in-depth and say, hey, and what are the release items? It goes and finds out whatever is being feeded either static or in a file wherever automatically you can write from the merge event. You can do whatever you wish to. And if you're getting bored, you can just ask, hey, get me a cup of coffee. So things like that. The idea is you can do static dynamic or sort of things. Coming back to the talk, yes. So we saw that it can solve multiple problems so we can control and say that, hey, Alice, do this. So I saw DevOps engineers especially having a trouble like my morning five o'clock or four o'clock they have to wake up and log into the laptop and deploy some script on some machine, run some scripts. This can be very handy. They can just feed in, okay, go to this machine and do that. You can connect the Jenkins or other CI things with it. And at the same time, you also want to ensure that nobody else can do it. In Alice, you can do those authentication systems. You can say that, hey, do only if it's me. And you can also say, hey, Alice, be more intelligent. For example, I have seen DevOps team suffering this, like not suffering, having this question again, is my release deployed on that particular server or what are the all-release on that particular server? You can just have this kind of setup critically. So whenever a release is going from whatever branch that in push event, you can save the data from there whenever machine, sorry, whichever machine the release is going, DevOps have their own way of scripting, finding out all the server details and that can be pushed in one file which Alice can keep reverting each release. And this is one of the interesting things which we did because I did not want to be a grandmother. So I did not want to tell everybody every time that this is a code freeze. We are not going to take more items out of this as such things we did in Alice. Whenever code freeze happens from there to test branch, it automatically reverts. It has all the entries, what is being merged during that period and it gives the quick details people can see, okay, is my code there, is getting tested and QA teams can plan their bandwidth, future. So what do you think, what can be the future? Apart from this, whatever is written, it remains, right? There is no single word. You can code whatever you want to. But what immediate future I am seeing is the continuous integration. The reason is simple because continuous integration requires all is the code commit data and Alice already have that. All it needs to do is run some checks and move it to the next staging server. So that is what I'm working on. Probably will be there. Code right soon, it's coming soon and some faces are like, you're gonna be kidding? Yes, I'm kidding. It's not coming soon, it's already there. We have open source date and you can try it and if you like, star it, fork it, contribute back to it. I feel I would love to know more stories around what problems Alice solved for you. And that, I want to give credits to a lot of people here. Mostly the problems at work and going to the, coming to the APIs and the photo credits, also I want to give to the unsplashed Google NGP. Sorry, so to summarize this, we started with solving one problem that was people were merging the unreviewed comments. We started with one problem and gradually we learned in the process that Alice could do much more beyond that. So now I hope you have idea about solving your own specific problems in a more automated way and an idea how the future Alice will look like. With that, I appreciate your time. Thank you. I'm open for Q and A. I can take few questions. Yeah, hi. All right, so I saw your checklist for developers before the merge is done, right? I know the developer's mindset is like, I want it to be merged right now. Just click the box and merge it. Now, how long have you implemented this checklist? How effective has it been? Yes, so the checklist we started using for our own remembrance. The first checklist which I shown in the slides, if you remember, that was for the release checklist. That's for sure we are taking care of it because we already did that mistake, right? So for release checklist, it's not a problem. Everybody follows it because then release things will go wrong. Now, developer checklist. Developer checklist, yes, it is hard to implement, but it's like there are people who actually do not want to miss things. They just miss because they forgot. So for them, it is very beneficial. And for whom, who after seeing also do not want to do, that's where continuous integration is coming in. So we do not allow the, we do not enable the merge button itself until those things are done. Was I able to answer this? Any more? So actually the thing is, we have one bot, I mean, Hockbot, so we have integrated with Jenkins. But the thing is my Slack user and the Jenkins user might be different. So I'll you control the credential things. Can you? It's simple. So I created a Jenkins. I want to solve with that. What I want to control is like we have production deploy through Jenkins. So I want to lock, we are triggering the bin. So Slack user might be the different one. And the same user might have the different username for the Jenkins. So how can you sync up the things? So answer is yes or no, you want to do that or not. So for us, if I can create same name as Alice, nobody gets to know about it. But what is the Slack user's username? Yeah, internal authentication when you want to do. For that users, whatever user you have created, you can do for that. There is no need to make everybody everywhere Alice. You just can name Alice internally for that specific user token. You can authenticate. Okay, only this user token should be allowed to do perform a particular task. But then you will not able to lock that whoever is triggering the build. Whoever is getting the build, I didn't get the build. Suppose I have a bot, anyone can send the message to the bot. So I have to log it in the Alice, not in the Jenkins. So what if I want to do it at the Jenkins level? Jenkins level. So everything, whatever message Alice. So Jenkins triggers a call, sorry Alice trigger a call to Jenkins to perform certain task. And in Jenkins, in post build, we have written, revert back to Slack. So we know that who did what. It's never open-ended that just do this. In Jenkins, we have always written a post Slack call to revert back and saying that, hey, I did this on this particular server. So people get to know. It's not like somebody personally talks to Alice and do something, no. So that way we are handling. Yes, hi. Can you help me a little more to understand this question? What do you mean by phases here? Okay, okay, I get it. So with Hubot, one thing is, when you interact via Alice through Hubot, Hubot has a scripting, it's called coffee script. It's just like a Java script and all you need to write is more of a regular expressions there. So probably it's like the more rich regular expressions you write, it becomes more natural language there. So people do not need to mug up or remember commands. They will just say plain English. I want to start this machine. Then Alice will understand, okay, which command to hit against it. People will come with plain, completely plain English. You just need to say, whoever joins new in, you just need to say, hey, just talk to Alice. They will figure out. So that's how I have improved in writing my own regex. I used to give to people. So that's where it came up with more natural style of understanding. Okay, so we're cutting down questions because we'll be available outside. You can talk to them later. And we'll have a QA session as well. Thank you all. Thank you for timing. I'm all around here. I would love to chat if you have something in mind and some ideas, more ideas you have to implement in Alice. Come talk to me. Thank you.