 Hello, all right. So good morning, everybody. Let's get started. I think we're just a few minutes late already. So this session is about accelerating development workflows primarily on OpenStack environments or private cloud. This is where developers really start to write code, run the build process, and then finally go to deploy. And NetApp as a company, how do we actually integrate a lot of these processes in the back end to accelerate the build process and accelerate the development process? So that's what exactly this session is about. My name is Vikash Roychaudry. I've been at NetApp for the last 16 years and was mostly focused on DevOps and integrations with OpenStack and a lot of other cross-functional activities that goes on in the organization to come up with a complete DevOps solution end to end, including PASS, IAS, using OpenStack. And then the end goal is to have a complete solution for a development environment right from writing code till we go and deploy the application into production. So today's session we'll be covering, first of all, we'll start to give introduction about who we are and then we go into the development challenges and then talk about the NetApp advantages. And there are a few use cases that I have. And then after this, I will be pausing for some time to switch over to a demo. And I've been having not a good time with the demo gods, so I recorded the demo. It is not a live demo, but it's good enough for you to actually see what exactly we can actually provide to accelerate the build process. And then we conclude. So NetApp as a company we have got about $6.1 billion, $3,200 plus patents that we have in our name. And then we have got about 12,000 employees today and we've been headquarters in Sunnyvale, California. So primarily what are the challenges of what you normally see when you're doing an application development? So first is how do I actually mitigate my risk? I have got a source code, I do not want to touch that until I really confirm the changes that I have made and commit those changes back to the code repository. How do I actually mitigate that risk in a lot more scalable and a lot more faster? So now if you look into all the conversations and presentations that we heard from Gartner and the keynotes and a lot of other presenters in the last couple of days, it's all about the by-model IT and how Mode 2 is taking over and the kind of perspective that we have been seeing from a lot of our customers where they talk about how is the agility, the speed, the way they can scale. And that's the reason why open source and open source tools and open stack comes into existence and it's been so powerful today that people are trying to embrace the entire setup with the open source very closely and very quickly in the environment. So apart from that, it comes down to the economics. How do I actually control the cost and net up as a company with the integrations that we have done with open stack? And various of the components that actually completes the entire develop architecture of the process. That itself is a huge enabler for us to enable this open source tools, the integrations with Jenkins and we'll talk about more of that. So that exactly reduces the overall cost if you have to see as to when you process, store and manage data because that's where we actually come in to make your data persistent, to protect your data. And that's where we actually come in and provide a lot of these integrations at the top layer from a developer perspective all the way down when you start to penetrate down to the infrastructure layers including the IAS which is open stack. So now if you look into this diagram on the extreme on the other side of the top you would see the waterfall model where you start to design, you start writing code, you build it and there's a process which is not iterative. It is a waterfall model where the go to market is very slow and the dollar amount happens at the very end of the cycle, the end of the cycle. But if you look at the left one, left hand side you would notice that there is a iterative process where you can keep on testing, you keep on building, you are doing a continuous integration and a continuous delivery. That means every time a build is ready you are ready to promote it to production. So that is where the continuous integration and that is where you're having a faster time to market. That's where you see the value. And from an open stack perspective the virtualization that we actually provide and the open source tool that actually integrate and actually leads to just to reduce the amount of time that you take not only to deploy the code in production but also reduce the cost of your overall infrastructure. So in this slide I would like to say how do I actually achieve faster time to market? So first of all, you have to give a developer focus on where the continuous integration is happening and how fast the code is can be transferred from a development process to a deployment process. At the same time, continuous integration environments, how do we actually build that up? How do you create a template? How do I actually have much more faster adoption on the development process? So how does a developer go and create the user workspaces? Faster, how does it scale when I have lots of number of developers in my environment? And then finally, it comes down to a cultural development, cultural shift in the development process where it is more of an iterative process and more testing for better code quality. That's exactly what is important because you need to be agile and that's exactly what we're trying to figure out and how do we scale and how do we improve in the speed so that you can actually have not just a faster time to market but also faster time to value. So the innovations and the value that actually come out of that. Now this is another sample infrastructure that we have put together for a devop practice at NetApp where we are actually having the bottom layer, all the NetApp components and then we're stacking it up all the different layers of OpenStack and you're using Liberty for that matter. Now if you look at this, we're using Cinder but the Manila part is not there because it's Liberty and there are some challenges in the maturity of Manila in this release but with Mitaka we'll be having that all integrated with Manila. Now if you stop by a booth in the exhibit floor we already have a very good demo on how to use our NetApp technologies which has been integrated with Manila which we actually showcase that if you guys haven't seen that demo please I will request you to stop by and take a look at the demo and that is exactly the same technology we would be using for as we start to form a solution around Mitaka moving forward but as for Liberty this is the architecture we chose to go and if you look into the different components over here we are building this infrastructure all for devops starting from the storage component and the NetApp technologies we are using NFS as a layer to communicate with the data volumes that we are having on NetApp and at the same time we are also having NOVA volumes NOVA instances which have been spinning up UNIX and Windows platforms and which will be a part of their build form you're having Jenkins, you've got Git and API services running at the same time so literally have everything as far as the infrastructure is concerned and then you start to build the workflow on top of that. So based on this particular template or the architecture that you see again this is a sample architecture this could be done in various multiple different ways yes we are putting together some set of best practices in which way you can get the best optimized performance as well as value for money with respect to OpenStack there will be a lot of documentation and blogs coming up and there is already a blog already published around that so but this is the architecture which will be focused on the rest of the presentation as we move forward. Now we as a company we've been always starting to contribute to the open source community we have been contributing to the OpenStack community using drivers to senders, drivers to Manila, SIFT so that we always stay close in touch with the real process and the business requirement and these are the different plugins we have actually introduced and available today so the bottom one is actually called Code Easy that's available in GitHub this is primarily for system and storage administrators which actually uses NetApp technology these are a bunch of scripts which actually can be configured and tied into a workflow for a developer and just above that is the P4 Flex this is actually for an SCM tool called Perforce I'm not sure how many people in this room are using Perforce as an SCM tool for your development purpose that is again another joint development that happened between NetApp and Perforce to actually come up with another plugin which actually runs in their admin so if you are a Perforce admin or a user who is working in a Perforce environment they are able to run NetApp technologies directly from the Perforce layer they don't have to know what exactly are the NetApp technologies underlying that and what are the commands because these are already part of a plugin which is being co-developed by NetApp and Perforce and based on that I will be showing a demo using that P4 Flex which actually you can use it anywhere as long as you are using a Perforce environment now the top one, right on the top we are trying to put together a plugin for Jenkins now Jenkins is a very common CI tool so we are trying to put together an architecture which can actually connect to any CI tool not just Jenkins but because Jenkins has been so extremely popular we are trying to go with Jenkins but that architecture can actually fit into any CI Travis or any other CI tool that is available so if that happens you do not have to know any underlying technology of NetApp because that is already going to be part of the OpenStack infrastructure but from the way it has been configured at the right of the top from the Jenkins plugin you can call those functions directly from the tool itself so that is going to be available in the second quarter of this year and I think we are hoping really a lot of our customers who are using OpenStack in their environments in a developer scenario Jenkins plugin would be really big attraction for connecting that with the NetApp technologies now this slide I would like to highlight where we actually make an impact on the developers workspace or the workflow so first of all is the productivity the biggest thing that we are trying to have and I have got some animated slide later on a build slide I will show you in steps where the use of workspace creation today if I have talked a lot of different workspace sorry developers and organizations and teams where they say hey we got to copy those things we do an arch sync to that so obviously it takes a lot of time because a lot of space but that is the idea that we have to do it instantaneously and at the same time reduce the amount of footprints the storage footprint for a lot of these user workspaces because keep in mind once those code changes have been checked in in the code repository you don't need those workspaces anymore because you need to move on to a different kind of a branch development branch and you need to start working on so that is where the focus has to be how do I instantly create these sandboxes which have been transient which are temporary in nature and then once I'm done I'm going to blow it away so that's where NetApp technology actually helps in doing it and that is where you can see there snapshots and flex clone now you would come back and say hey we've been hearing snapshots very frequently everybody uses it and what is different with NetApp right now the biggest difference with the snapshot is basically this is used for data protection that's the base underlying okay I create a snapshot I protect my data but in our case we do not do a copy on right we do a pointer based to the blocks the snapshot they are thin snapshots that means they do not take additional space so and that is instantaneous that means you create a snapshot immediately and I will be highlighting that in my demo later on how soon we can create a snapshot with the we have taken an android open source code which is about 67 gig and we are creating snapshot almost like in less than three seconds so we are all instantaneously creating a snapshot and that snapshot is primarily a read only so when you create a clone you are making that snapshot as a read write so then when you give it to give a workspace based on a clone from your snapshot at volume which has got a code repository your developer has that workspace created instantaneously and that clone does not take any additional space so that's the importance of net app snapshot and cloning compared to anybody else using having the snapshotting capability we are doing the further data protection and we're also adding acceleration to the development process without taking additional storage space and then the second one is the build completion time and I'll show you in the next slide when which is a build slide I'll be going through a different processes we are creating an environment a template for a CI environment which is a continuous integration environment where you can actually have this entire build process set up in a way that you do not have to take extra time it will be mostly doing incremental builds and it will be a lot more faster compared to any full complete builds that you will be running in a day or in a couple of days depending upon the schedule that you have and the third thing is the overall efficiency because the snapshots and the cloning mechanism are thin provision and you do not take additional space we have got customers reporting back at us saying that from a 60 terabyte I can reduce that to a three terabyte space during my development time that is about a 40x improvement as for a storage efficiency is concerned so that enables us to say hey we have been a storage vendor but still we are advocating our customers to use the processes in such a way that you can reduce the cost and reduce the storage footprint yet get the storage efficiency out of that so if you look at this slide and this is the first enabler and value that we are providing and if you see here we are putting together a continuous integration environment here and you have got Git and your Jenkins and you have got code repository it is obviously running on open stack environment as I was showing you in the previous slide so this is your code branch you are having the main code you have got different development branches so I will use dev branch one as an sample example in this particular slide when I was moving forward so if you see here there is a Git repository you are taking a snapshot now this snapshot is primarily for backup purposes so any change that happens in the repository along with the show number that you are having it probably has to have a snapshot to actually take a backup of that that is the only scenario where you need a snapshot for the code repository now as we move forward we create a volume now this is something which you are creating a CI environment you have got a user called Bob maybe I am using the name Bob because I will be using it in my demo and he is the CI owner and this is the environment that he is creating so he is creating a volume right there for dev branch one which is syncing up all the source code and populating that in the dev branch one volume and then putting in all the resources over there so if you see here you see the compiler sorry T is the tools compilers, libraries, RPMs all of them have been pulled into this volume synced up and then you run a build so once the build passes then you take a this becomes your baseline and you take a snapshot of that volume so now when the snapshot is created developer comes in and says hey where is my latest snapshot with the changes that I was looking for all updated changes, the recent ones for dev branch one so immediately he goes and starts clicking a clone now keep in mind this clone is a completely prepackaged that means you got everything in that clone you got your source code your compile binaries because you ran your build already and you have got all the dependencies your tools, your libraries, your compilers everything is in there and then you start your CI again depending upon the schedule that you have to run how many number of developer builds versus a CI build in a day your CI build kicks off and then when CI passes what we do is create a Docker image and move it over to a different location which has got a complete prepackaged environment, why? suppose six months down the road a developer says hey I hit a bug on a SHA number or a change number which was done a month ago a few months ago how do I get back to that environment to replicate the problem so you just go back and pull up that particular SHA number or the change number and spin up that environment in a container or in a microservice and you're all good to go to start testing out and replicating the problem right so and again as I said this is a complete prepackaging of the software because everything is in there in that image and then what happens this guy the developer in the workspace makes some changes the changes are committed the Jenkins summits the changes into the repository as soon as that is done you take a snapshot again as I said the snapshot is a primary for backup right and then this change is automatically going to be populated in this volume once that happens now this becomes dev branch 1.2 so then you run another build build passes you take another snapshot so when the user says hey I want to check on the latest one with the changes coming up from some other different user you already got 1.2 available you take a clone and you start working on the latest workspace so if you see here the point that I'm trying to make is the instantaneous creation of workspaces for the developer and with the same time you're constantly updating and what happens here is when you are running these builds the developer builds they're all incremental in nature so what happens you do not use much of your computer resources there is not much of network traffic and you are not hitting the get repository all the time you are actually updating it all of these things happening at the dev branch 1 volume which is the template that you created for that particular development branch and when this then a CI test creates that image is created again with the new change number and then the changes are happening in that location is now committed back and the same process repeat itself right so what happens these are all sandboxes these are all gone with the users are done you destroy them so basically you got a workspace with no extra space that has been taken you're getting the storage efficiency with a little reduced cost and in the cloud scenario if you think about it you are being charged there is always a metering process that is going on and from a storage perspective you are getting the storage and at the same time the efficiency and then you can instantaneously blow them away and this hardly needs any kind of a computer network resources everything has been handled by the storage layer and then finally what happens is you can promote all the changes to a QA scenario for staging and finally promoted to a build earlier deployment in a container so what comes down is is a complete risk mitigation how do you mitigate risk because you are isolating the code base from the repository to a template to a developer scenario so we have got a a complete isolation of the code base and the work that has been on the changes that have been done by the developer and then we are actually having it this tourist cost down you're using cost because you're not taking much space of in your in your works places that you're creating and instantaneous work creation so it takes them less than a minute I'll show you in the video how quickly we can actually create these uh... workspaces uh... instantaneously then as I said this is all going to be part of the plug-in and as you saw in the previous slide we already have a code easy which is available for system admins we also have another cost before flex from per force and we're working on a Jenkins plug-in right now so a lot of these plug-ins are going to work do all the work for you in the back end but I'm just trying to show you what the process is in order to enable your development process and accelerate that much more faster now this is another advantage now supposing you have uh... database your database has got about twenty thousand objects and you are trying to grow that number to sixty thousand objects you want to drop some schema makes a modification to application logic and a lot of those things in your database right so what happens is users come in you use a plug-in depending upon what is available using a Jenkins plug-in or p4 flex or code easy doesn't matter then you create a clone of your database so you don't touch the clone so your production database you just clone them once you clone it you mount them you can mount them directly onto your VMs and then over VMs or you can use containers to mount them we actually released last week on the twentieth we released a container plug-in netapp uh... docker container, docker volume plug-in which can actually create volumes and you can destroy volumes directly from the container itself you can actually mount them for the volumes which are already so supposing if you are having these clones which are nothing but volumes you can mount it from the docker container or you can use it without that so what happens is once you do that you start to modify test you do your unit test and then you start to build the changes that you do in your workspace workspace is now different because you added more objects to that so what happens is you then start these are the use cases normally that you normally changes in the database you do run the regression so what happens you start to promote those changes when you promote those changes you start testing it you test first fix passes, second one fails then we do a rapid restore we have got something called snap restore which is again included in this plug-ins to enable you to restore rapidly so instead of going back to your previous test and copying back this lot of these things back again which takes a lot of time you do an instantaneous of snap restore then you after the restoring this then you start testing more testing and then finally this fails again you restore and then runs test basically is a fail fast fix fast that's the process and then what happens is at the end of the day the more amount of testing you do you're saving a lot more of cycles because you are not going to you are taking less time to revert back to the previous state you're getting a better code quality and because they're all instantaneous it is a faster time to market so these are the bigger enablers actually to using net app technology because we've been asked all the time here you are a storage vendor what are you doing in this space and development because a lot of these things we actually do this today in house we in our own code generation this is what our process is today because we also have to see how fast you can develop and how much how agile mode we can actually adopt to get our code out in the market for our users another use case supposing you have a scenario like this where you have uh... entire develop environment on open stack and then if this is your and then if you're using docker containers over here if you look here if this is your directory structure one thing keep in mind you have some projects you've got android you've got the users and bills and these are all your cloned objects i got a customer uh... i think a week ago i was at a different conference it says hey we have got these users who constantly rebuild this uh... what workspaces which obviously doesn't use the flex clone technology but if i destroy them every time the path goes away i lose the path and i get an error how do i do that and i have seen in some of the presentations where red hat promotes namespace and how do you actually have all these things laid out in the file system in the namespace we actually have a default namespace and junction path where you are able to orchestrate your uh... containers of your your volumes over here to your containers that is running i'll show you in a moment how it is doing so if you're mounting this if you see here look at the mount path you're mounting it all the way up to here but when you're running this what's going on if you see here the path over here the projects you can go directly to this location so if you have to blow away this cloned object which is transient in nature you do not have to compromise on the path because when you're doing an nfs mount very likely you'll get a nfs tail handle because the path is removed but you're mounting it and that is not finding that particular location but in our case it doesn't happen that way because it's all going to be part of the orchestration layer and how you actually access those cloned objects from the container itself that's the flexibility we are providing with namespaces so what i'm trying to highlight here is imagine you have got an nfs share which has got all your tools in that location you use a container, spin up containers where you actually point it to that nfs share that can be shared across multiple containers so you can scale and share the same set of tools, supposing you're developing applications in the java, all your java tools are resided in one location so that's the advantage that we are providing with reduced manageability because you don't have to mount each and every volume so that when you destroy that location on the volume you have to rewrite or remount the path again you don't have to do all that stuff so now i'll spend the next five to ten minutes for showing the demo and this demo was actually done from AWS in a hybrid cloud model we have got the NetApp storage on a private store on a co-location and then we are actually running Perforce as an SCM tool from AWS and then running the entire workflow of a code development of Android open source code in this manner so we'll just go through this full screen so i don't know why my screen is cut off over here but i'm trying to log in over here uh... from Amazon trying to spin up an instance with uh... Perforce running Perforce instance starting off a Perforce instance over here from AWS and from the the party session we're logging in we're trying to see here if you see here do things you're mounting the NFS share right here from the storage itself thank you so so when you do a mount point over here you see the mount right there and the pre-port report is located you start that and you're running the scripts and if you see the scripts are already running now you're logging in as Bob Bob is your CI user and then he's creating uh... environment just like the template that i showed in the previous slide he's logging in and doing a pre-for-flex volumes to list all the volumes and if you see here these are the volumes that are present today when he starts checking or checking the size number of volumes that you have there then what i'm trying to see here is you're doing a build environment for a slow traditional checkout which you normally do a pre-for-sync and then do a make and then we're also using a pre-for-flex development flow using Jenkins as a template that i showed you earlier so this is uh... the directive structure if you see here you've got the different code Jenkins build the nightly build the release builds then you have got bob under the user with slow developer and test fast developer and then you have got the various different workspaces so on the left hand side you have the slow developer where you actually having in the left hand side and that's the bob Jenkins the CI owner and then you have got the fast developer terminal window and we'll go through this process so if you see here on the left hand side we're starting off creating a workspace using p4 client and then we're doing a pre-for-sync and then it starts to compile the code so this is the process which is a normal behavior in a scenario like this so when you start that you put a path to your depot over there and configuration file you're doing a p4 client to identify to the proposed database that this is the workspace that you're creating and you're providing the path in the config file and then once that is done you start the pre-for-sync process and then you head out and grab a cup of coffee while this is happening you're syncing up code now on the right hand side while this is happening let's see what bob the builder or the CI owner is doing right now so this is the flow that we follow if you see here we are creating if you remember the slide that I showed you we're creating a volume for a dev branch and then we're actually running a p4 sync you're syncing up that volume and then we are running some of the build commands the scripts for running the builds build passes okay we create a snapshot and once the snapshot is created then we start working with the this is the build flow and then we start to have this guy the p4 flex snapshot is created right over here once the snapshot is created that means whenever the user comes in and says hey whichever snapshot is available for me to pick up for my workspace and the next one is a pre-force workspace developer flow which the developer comes in and says checks in what the snapshot is and then this is where it does a change ownership now change ownership today we have a script to actually change ownership of that user but moving forward it actually is going to be a native feature in our on-tap or net app code because when a user logs in it will be logging in as a username and UID and GID so that UID and GID will be used during creating the clone so if you look here let's see what Bob is working on so he just checks into the volume and then he looks into the directory of Jenkins build and he makes a list of that all the volumes all the files are located there and then when he does a p4 change and checking what changes has happened he says finds the change number 29 is already there but the snapshot does not include sorry the volume snapshot does not include there if you see here so here is creating a snapshot for change number 29 and if you look at the creation time is only three seconds so that is what I was talking about how fast we can create snapshots with net app technology and then once we list all the snapshot now you see build number 29 listed over there so once this this is the the slow builder is still making the compile at the sync so that right now the fast developer comes in and checks what is the snapshot available this is 29 so he does list all the snapshots over here finds the latest snapshot as 29 and then describes the clone and you look at the time that we take for the clone so the clone completes in 20 seconds now once the clone is completed let's get into the workspace and see how owned by Bob and DevOps it has to be owned by the fast developer the ownership has to change so we are running a script right now to change ownership this is taking time based on the size of the code but that is changing in the next release of net app operating system that we are releasing in the summer this year so it will be you see here it is done in less than two minutes you've got everything in his workspace right now so now you see the productivity has now improved immensely and that is how we actually do it internally at net app too for our developers so now you go and make some changes to the path and make that as a p4 client so to register with the proposed database that this is a user workspace and then if you do a now you're doing a p4 a flush that means you're only thinking of the changes that has happened on change number twenty nine now few things keep in mind we are not running a compile we are not using any computer resources there is no network traffic nothing everything happens on the workspace itself only thinking of the changes that has happened since the last change happened is number between twenty eight and twenty nine so once that is done we can start doing editing a file so let's go and start to edit a file and make some changes and then commit those changes into the proposed depot so if you see here all the compile system files are there so what happens here if you make only one change in your file one line of five lines you're only running to compile those lines of changes that you have done and that is how we are reducing the build time also that's the reason when i was showing you the slide before i was mentioning this is how your flow works so if you if you look over here the final edit so we are editing your file so we are doing a p4 edit making a change and adding a line to this text file and as soon as we save it you'll see the change number is now thirty you see here change number is thirty so once you have that you then start to do a p4 change dash m1 and then start to sync up what changes has been done so if you see the clone that we created this is the amount of space so sixty seven gig of total source code is only taking about eighteen megabyte that is a huge space savings right there think about when you compare this with your regular sync and copy operation this is very minimal and it actually took around four minutes to complete the entire workspace almost very nothing no storage space taken so now for the slow developer is still doing the sync operation so it completed after an hour later and then it is not done yet we have to compile it so the compilation takes about another process for the slow developer and then while we do that we initiate that the make command so while this is taking a longer time for the slow developer on the left so it took about hundred and eight minutes by the time the fast developer got the snapshot made changes submitted changes and is done so it is instantaneous we take very minimum space I would say almost nothing from a sixty-seven gig to an eighteen megabyte it's nothing from a storage footprint and we are done because you're only running the compile for the lines of change that you're doing and those are all incremental developer builds that you're running and then the CI owner can run a complete incremental bill of a full bill at the end of the day depending on the schedule which does not impact any of the developer so this is the template that a CI environment can have in order to provide that to the developer to expedite or accelerate the development process now going back to my this is all the demo now going back to the slide I got one more just to summarize just to summarize instantaneous workspaces the creation and deletion now again you have to delete those workspaces also they're absolutely incident they're just sandboxes just blow them away once the developer work is done and then is reduced checkout time you don't take much time you don't take much space improved code quality because you continuously keep on testing it because you're drawing the test based on a template that you created in your CI environment and reducing infrastructure cost so if you look in the overall impact from a storage to the infrastructure above that the amount of network traffic is very little the amount of compute resources you're taking is very little and we are actually taking it to the next level where we are going to run Docker containers on top of those compute resources that we are having the VMs, Nova VMs that we are having so probably by the next time the next OpenStack Summit event happens later this year we'll be having much more advanced configuration with Docker containers running on top of that but bottom line that I'm trying to make here is we are as a storage vendor the native technologies that we have and the plugins that we are working in partnerships with a lot of different development workflow vendors out there like the CloudBee Jenkins SCM tools available that has enabled us to give us a complete what we call focus on the technologies directly which can impact the overall workflows in the development process that's all I had any questions that's a great question and I'll take you to this slide that I had earlier this one so if you see here the bottom part is all system administrator yes if you use the bottom plugin it'll be very system driven where you have to have the system administrator doing that but if you go to the middle one that is where you're if you're using Perforce your Perforce admin or the user can actually generate all that from a Perforce command but the top one that we're releasing that answers all your question because it is completely seamless of what NetApp technology is underneath the covers it'll be a user interface which will be tied into a Jenkins template and from there you'll be making all the choices which are the snapshots I'm having I want to create a workspace it creates everything under the covers you don't you're not exposed to that at all so that is happening in the second quarter of this year we're almost done with that we're starting to test it so once we do it we will be having that for the open stack infrastructure for with the pass integration as well as for hybrid environment and AWS and any public hypervisor and we completely understand that because we do not want to expose a lot of our technologies to developers because they don't care and we totally understand that and that's the reason where the Jenkins plugin will be a lot more helpful because CI is something which is very synonymous to a lot of the developing community so that is something which we try to integrate that directly all right if I don't have any more questions thank you very much for your time