 Hey guys, good afternoon. Thank you for coming for this session. My name is Sameer. I'm the founder and CEO of a company called R2. What we're trying to do is, you know, use Android and Cloud for the benefit of the masses. So, you know, many companies that work directly with the poor, whether they're trying to provide financial services or healthcare, they operate through field agents and field agents who have a technology barrier, language barrier. So, we're trying to use intuitive touchscreens built on Android, you know, and sort of connect that through the cloud and make things happen. That's a little bit of our house. Now, before I start, just to get a sense of how many of you sort of heard of Jenkins or continuous integration first? How many of you sort of all work with continuous integration? Okay, so that's a large number of people. And so you would have obviously heard of Jenkins, right? And there was a session by Costa earlier, which sort of introduced Jenkins. So, you know, we were also very excited about continuous integrations, right? It suddenly means, okay, now you can build as a process and things like that. Before that, you had a very ad hoc process, right? Everyone would suddenly say, okay, I'm committing changes, wait, wait, don't push stuff to the cloud. I'm going to do this. And then when we got Jenkins, which is this continuous integration system, then the problems suddenly changed. Then it became about, okay, who's going to run it? You know, who's going to sit with it and sort of wait for it to finish and do the next set of steps, right? Not everything sort of takes place only at Jenkins. So I'm going to talk about this new thing called Hooport, which can try and simplify this entire interface, right? And make things a lot more fun for your small team. So, so first of all, you know, I look at myself more of the suit, you know, because I also handle the business part, but sort of Jenkins, Hooport knows me like this, you know, the little mustache, is this clear? Okay, so I'm going to show you how you can make such images also. This is a fun part of Hooport, using Hooport, right? I've also hosted this presentation on this link. So if you guys have laptops and if you want to look at some of the scripts in better detail, you can look at, can I even go to this link? So let's start with the problem, right? So as I'm mentioning, this is the kind of challenge that you face in the small team. Suddenly the person who's designated, in our case, we're just four employees, right? And just because one of us knows a little more about than the others or has some idea of what the others are doing, suddenly it becomes my responsibility to be the build guy, right? And then suddenly I become the bottleneck because now people are committing and they start depending on you, right? And typically you have two sets of processes. One is you take the stuff to your build server and that gives you an output. Typically you store that on S3 or some sort of storage and then you get your cloud to pick up that file and sort of update this, you know, your cloud, right? So there was a nice session on Puppet before this earlier in the morning, right? Now, so this is what we face today at work. Then we came across this interesting deck. It talks about how GitHub uses GitHub to build GitHub. So it's really interesting. You should definitely go through these slides. I think there are sort of 40 plus slides or more than that. Is this clear? Not very clear, okay? So what he talks about is that they work asynchronously. Now, this is a team that's about 52 employees. They spread all across the world and different people wake up at different time and do work, right? And so for them, they have to work asynchronously, right? At a start up, you would like to have this flexibility. Then what happens is that, you know, so this is a small diagram showing that how a trusted developer becomes a gatekeeper and therefore the bottleneck. So what they came up with is a simple model. You have the master branch, which is always, which will always hold your deployable code, right? So whenever you suddenly need to deploy, you will take code from your master branch and everyone else will create little, little branches from this. Sameer will work here and and others will work on other branches and everyone can push and then they can deploy, right? So the idea was to make it more democratic, right? Now, anyone can sort of build, anyone can push. Of course, you need to have permissions and place. But the idea was to build a process that allows everyone to push and everyone to deploy. That's really hard. And that's where Hoopod comes in and does a good job. So what does Hoopod? I'll just sort of step to my screen. So this is my G Talk terminal. And you can see over there, it's not really on screen. Sorry, the resolution changed. That's why I connected the project. Is this visible? Okay, I'll use this thing then. This is visible? Okay, so this is nothing. This is the iChat client. It's connected to my Gmail. I'm going to say hi to him. Let me try and increase the point, right? So I say hi to him. He sort of responds by saying hi to your service. And I'm going to ask him how is my cloud doing? It's a simple question. So he's saying cloud doing fine. And I'm going to thank him for his service. So he's going to say you're welcome. I'm going to say hi to him politely. It's a nice speaking game. Right? So it's just a simple thing. It's a program that's running at the back that's simply sort of responding to your commands. But this becomes a very fun way to interact with the system. Right? So this is you what that it is a bunch of things. It's written on load. It's written with, you know, coffee script. And you can make so you can make a script to do anything. Right? So you can simply make commands that can respond using rejects. It basically understands okay, you said hi by thanks and things like that. And then it can run a command. Right? So what I'm going to do is sort of go back to the presentation. Just for completeness is sake, I'm going to talk about, okay, how can you install this? So instructions are fairly straightforward. You need node, you need the package manager coffee script. And then you can install you bought. Now what we've done differently is we've normally you bought is used with campfire or hipchart or one of those things, right? And those are paid services. Whereas we spend a lot of time on G talk. So we thought we'll connect it to G talk. And there's an adapter available for G talk. So we just straightforward use that. And running it is as simple you provide the environment variables, which are your, you know, G talk user name, password and sort of what what needs to run on and you can start this. Then so if you want to know what all it's capable of, you can simply type help and you'll get a list of commands that it can do. Right? So I'm going to go go into this a little later. We've connected this to talk to our Jenkins, right? So I'm going to say Jenkins list. So it's showing me a list of you know, jobs that we have running. And it's saying, okay, this one has passed this one has failed. And you know, these are all passed. Can you see this text is okay? So I'm just going to say Jenkins build. I'm just going to give it this command. And it actually starts a build job in the background. Right? So if you come here, there's this I'm just going to say and you can see that a job has already started over here. Right? And and I can go and I can see so I can see the log if I would like to and then it's doing its work. It's downloading from get in and doing other things. Right? And at the end of this, it you can see it sort of places it on S3 for us. Okay, if you see the last set of lines, it talks about S3 repository and things like that. When our servers, when you want to sort of refresh the code on our servers, they'll pick it up from that repository. Right? Now this is how your regular build process would work. Right? Where one person is sort of sitting and saying, okay, on the master branch, let me go build it. Let me deploy it on S3 and then run a script to run it on to the cloud. Right? But what about sort of your interns or other people who want to simply run tests to see whether they code worked or not. Right? There's something called as parametrize build in Jenkins. That is, you can provide parameters at runtime that can change the way it behaves. Right? So over here, you can see I have this simple project to configure. And it takes a simple parameter called branch. And so you need to supply what branch do you want it to build? Okay, if you look at our GitHub, so our GitHub repository looks like this, we have about three other branches apart from master. So there are three other people who are working on this thing, and they're working. And I can just make this a little bit. Okay, so, so these are sort of each point is a commit, right? This is how GitHub works. This is a beautiful way to define things. So now what I can do is if I'm interested in this building my branch and see how it looks, I can say Jenkins, you know, build months equal to some me. Okay, and I can see sent me a link, right? And you can see that it's, it's just waiting, there's some amount of quiet time it waits until you want to pull it back to view. So again, what this does is it can actually, you know, it's picking up from the same branch, the code, and it's going to run. And at the end of it is going to run tests, and it's going to show you the results of those tests. These tests will fail because I've sort of messed up with my branch. But this is how rest of your team, you know, they may not be necessarily responsible for the end product, right? I mean, the end sort of build process, but they can quickly run that test, and they can understand what's happening, right? And they can get quick feedback, and they can do it in sort of a sanitized environment, like, you know, your build environment, and they can get their own response. This is making sense. It seems something like you guys will use. So to enable this, it was fairly simple. You know, we just simply used we connected it to Jenkins as a script for Jenkins. Okay, so you know, the way GitHub, so GitHub is open source, the code for who bought, right? And they described it as the most, you know, a project that increases their productivity, and also project that decreases their productivity, it depends on how you use it, right? So there are fun things like, you know, you can type with your little board, you can type fuck me. Okay. And what it does, it gives you a little picture of a buggy, a random picture of a buggy. Say, there are various money scripts like this, mustache me and your name. Hopefully, you should see an image of me looking like mongrel pundit. There are a bunch of a doctors. I don't remember seeing a skyper doctor. But you could definitely Jenkins itself can directly work with like, as long as you can communicate with it. I mean, if your ports are not blocked, and it's still accessible, it should look shouldn't be a problem. So the way this is working is you're using, yeah, sorry, this is how I look like mongrel pundit. But the way it works is so we will go a little deeper into that. And I can show you how you can write scripts, right? But what we're what we've done is we are hosting Jenkins as a web app. Okay, and on that same instance, we're also storing who bought. So who bought is listening to a particular socket, right? In the previous slide, you saw port 555 is listening on to that port. It's interacting with Jenkins using HTTP protocol. Okay, so they don't need to be on the same machines. Right? There is there are other ways to interact with Jenkins, but we're using a simple HTTP. So a bunch of other things that you can do with this, or you can have a lot of other funny scripts. Well, you have to be careful, some of them are quite inappropriate, not suitable for work. Like, you know, commit message, if you sometimes you can't figure out a nice commit message, you can, you know, refer to this. And then there are some funny codes. Yeah, definitely. So what you can do is you can use that you can write your own script, right? So what I'll show you next is how do you write your own script? Okay, so how many of you sort of work with coffee script before? Okay, very few people, but how many of you work with JavaScript? A lot more people. So sort of coffee script is like another level, a higher level version of JavaScript, you know, does away with curly braces and things like that. It looks a lot like a functional programming language, but at the end of the day, it's JavaScript. So go to this link, just to sort of give you a sense of the variety of love. So this is a, these are all the scripts that are out there that, you know, that can work with who bought, right? And so most of them are sort of funny scripts, but there are a few which are like productivity related. Hey, so I mean, I'll leave this for you guys. I can't see anything right now. So how do you write a script for who bought, right? So you saw my first script, that cloud script, right? It was actually a sham because all it does is it searches for the word cloud. And then responds that cloud is doing fine, right? It's fairly simple. It's just three lines of port. This is what's called a ton dog. That is, this is what's displayed when you do help, you know, when I type the help message, it will assure me that, okay, if you type cloud, you'll get a reassuring message saying, you know, cloud was working fine. This is sort of how you export a particular function. This is simple, you know, regex that you're doing, you're just checking the message, you know, whether cloud was mentioned in it or not, and it's case incident insensitive. And then you just send out a simple message, right? Cloud is doing fine. Now this is a fairly simple script to do, right? I mean, it's very as functionality. But this also shows you what all is possible, right? Moment you've done your regex expression over here, now you can do anything else you want. You can reach out to other systems, other services, web services, or you can even run sort of shell scripts, right? So the next thing that I'm going to show you is, you know, an interesting thing that I just wrote today. If I want to get a list of all our servers, right? So we use the right scale, right scale to manage your Amazon infrastructure. 11 servers up and running at the moment. And I'm just getting sort of, you know, a simple nickname for the server and a status that it's operational. And if I click on the link, right, so I click on this link, I can actually go to go there and see my server and see sort of graphs associated with it, right? So this is, I mean, this is the right scale. This is not anything. Now you can sort of see graphs. And the next step for us would be to sort of get these graphs directly into our G-TOP, right? So you directly say, okay, fetch me CPU levels for this particular server, right? Now how do we do this? Right? So what I did in this case was, so this is a regular expression, RS space list that I'm searching for. As soon as I match that, I check for environmental variables that have been set, I use the name, password and account number, and then I run a script. Okay, so the script that is running on the server, right? And the result of the script, I simply put that onto the message and I send it out, right? So those of us who are sort of familiar and comfortable with shell scripting can easily use this. Now what is the side? What does the script look like? So look at the core script, okay? So it's a very simple script. It's taking, you know, the authentication, you know, username, password, and then it gets an authentication token from that service, and then it goes and finds out, okay, how the server is doing, right? I get an XML, you know, it's the response, right? And the response looks, okay, I'll show you the response later with that sort of immaterial. And then I run a Perl script to parse that response, right? And what that looks like is, again, fairly simple. It's just simple XML parsing, right? So those of us who are comfortable with sort of command line and Perl and things like that can set up real complex jobs, right? And all you need to do is simply match your regular expression and kick off events. So it becomes fairly interesting and sort of the rest of your team can do. Now, coming back to your question about can you have permissions on this? So your permissions would, again, lie on this, right? You can get the user name, you can match against the user name and say, okay, this person is allowed. Sorry? Yeah, so, so Hubot has has only like, you know, two properties to it, right? So it has its own username password from which it signs into your GTO. And the second is it can whitelist certain user names or it can whitelist certain domain names, right? I don't want you guys to suddenly add this guy and then start running jobs on our system, right? So, so we whitelisted and said, only if you have the rest of the stuff, you can sort of build on your role over here. The best way to start on building scripts is to look at someone else's script, right? Just sort of get a sense of how they're structured. There are a few interesting scripts, you know, the typical examples people share are, you know, there's a tweet script. Okay, so you search for a term and space tweet and they'll find you all the tweets that reference that term. So like if today we've been doing root com, right, so we could do a root com tweet, sending me, giving me one person's, yeah, so it works. So, yeah, these are a certain set of links and resources that are placed over here. You guys can look at them. Apart from that, do you have any questions? Is this sort of, what's this useful? Sorry? How different is it from your IHC? Yeah, so I'm not sure about how you extend IRC capabilities. Over here it's much easier to extend the capabilities of this bot. So, if you guys work on Hiroku or, yeah, if you guys host your servers on Hiroku, there is already a ready-made infrastructure for you called Janki. Okay, so it's built on Jenkins by the GitHub guys and they have a nicely packaged thing. Now, I'm pretty sure the same thing would have been possible in IRC. This is sort of an easier, you know, thing because sort of the world is headed in this direction. But, yeah, so a lot of people use this typically in sort of an IRC mode where there's a group chat, right? So where you have sort of group spaces or a group chat room or things like that, right? So, the campfire allows you that, hipchat allows you that. GTalk sort of is more individual. So if I add someone else, so this is the downside of this actually, if I add someone else to this conversation, who doesn't understand what the messages are being directed at him or not. So you have to sort of send, you know, based on his name, you'll have to send a message like saying R2, whatever my command is, right, for it to understand. If there are multiple people around, if it's the only one it can sort of understand your commands directly. Have you guys worked with something similar or what are your sort of pain points when it comes to build processes and what are the optimizations you guys have done because we would be definitely interested in understanding how can we improve ours. Come online then you can directly sort of interact with Amazon API, is it? And Jenkins API. So the idea is to sort of simplify the interface, you know, to make it sort of cuter and easy, may not be really good at it. No, no, you can send images and stuff, you can send, say it has to be text-based data, right, that it can it can be made to do a lot of other things, right, you can call API as a other system, you can, you know, so there's a thing that, you know, you can, someone has sort of done, modified one of the scripts to play music in their system, in their office, right. So someone can say, okay, song, and sort of go and play that song. I mean, there's no limit to what you can do with this. Not yet. But you could do that. So I mean, at the end of the day, a new job creation is a post command, right. So you could sort of write syntax for this. Same. Send anything. No, I like this more because sort of we have only these servers, you know, so our model is we have these servers, you're constantly updating code, and those servers need to be updated. So the build jobs are made the same. Yeah, so you can also Jenkins has the ability to sort of sense change on GitHub. So if you, you know, commit code, actually the way it works is the other way around. When you commit code Jenkins, GitHub sort of sends a ping to Jenkins and says, okay, code has been updated on this branch in this repository. And if Jenkins has been configured to pick, you know, just automatically build anything and everything, then you can do that. So, you know, as and when you update your code, it can automatically get fit. Yeah, that's what I was saying. So yeah, you can go and manage Jenkins and you can add plugins to this. Let's open up. So you can add plugins, typically, but you could use it with any other. But, but the important part is that system needs to have books that it can expose to Jenkins, right? Otherwise, Jenkins will never know when something's happened on that system. Right. So what would you do? You would put it in a cron or what you would say, yeah, that makes sense. You can say poll every five minutes or an hour or so. But GitHub has hooks that it can expose to Jenkins and say, okay, you know, when, as soon as you commit, I'll sort of let you know that a commit is taking place. Let's say, right? So do you mean even on successful? We may have successful. Yes, yeah. So it has a setting where it says, you know, notify the person who broke the build. I can show you. Email notification this last part over here. It says send separate emails to information support. So I mean, that definitely depends on your sort of project. In our case, these are sort of the things that need to be executed. So I'm pre-compiling. I'm removing the pre-compiled photo. This is sort of just a test. But at the end of it, you see an auto test and it stops there. If you can see this. If I wanted to do a bit and also decry. So that Jenkins will stop automatically on its own. Yes, so what we do is, what would I do a lot is decry. So we will be doing the shell and use badminton. But I think it will be most built over the catastrophic. So I think it's quite good. We basically then use scripts to then send a bunch of commands to where we're going to deploy to from the after it comes with detected using badminton. So we then get here. So like if you see over here, these are all the commands that you need to sort of put on to S3. Right. But if it fails anywhere along the line, it'll stop really in shell, but you can add build steps and you can say, okay, what needs to happen? Post your build and things like that. This is all that Jenkins has. Is there anything else? Okay. Thank you so much. Thank you for coming. We finished early. Good.