 Hey, welcome everybody. Thanks for joining today's webcast. My name is Rebecca, and I'm a content editor here at GitLab. Today, we're going to be showing you some of the highlights from our latest release, demoing the biggest features and taking your questions. And I'm quickly going to go through a couple of housekeeping items before we get started. Firstly, this webcast is being recorded, and we'll share the recording via email to everyone who registered. We'll save questions for the end of the webcast, but please feel free to type them in the Q&A as you think of them. It's located at the bottom of your webcast console. As many of you know, we ship a new version of GitLab on the 22nd of every month. This month, we released GitLab 8.16, marking our 62nd consecutive monthly release. You might have missed us last month because of the holidays. We didn't do a webcast for 8.15, so we'll cover that and 8.16 in this one. Today, we've got two great presenters. Mark is our head of product, and he's been working on bringing you auto deploy, web terminal, and Prometheus monitoring, which he'll talk more about later. Our product manager Regis will talk about time tracking for the community edition, show other improvements we've shipped in 8.16, and tell us a little more about what's next for GitLab. After that, you'll have a chance to ask any questions you might have. For those of you who are new to GitLab, I'll start with a quick intro to Git and GitLab, and then I'll pass it over to Mark and Regis to show us what's new. At GitLab, we know that the right tools can help you to ship quality code faster, reduce effort, and cut administration costs. So we're redefining how software is built to provide the most efficient approach to software delivery. With a unified experience for every step of the development life cycle, GitLab helps teams to create and deliver quality products. If you're not familiar with GitLab, it helps to start with what Git is. Git is a method of coding that allows developers to store a local copy of their source code, propose changes to it, and share those changes with others. Since each developer maintains a local copy, it's incredibly easy to work offline and merge changes later. This is called a distributed version control system. Git was designed for distributed teams that have to work together across geographies and time zones, but it's now common to find teams based even in the same office using it as a tool that helps them to iterate faster and collaborate more naturally. GitLab is built on top of Git, and it's an integrated set of tools for the full software development life cycle. Our platform includes Git repository management that acts as your single force of truth in a distributed version control workflow. It also includes code review and this tools with tons of collaboration and workflow management features. We've built in an issue tracker with issue boards, cycle analytics, time tracking, and a project wiki. These features help teams to work more efficiently and can be used by non-technical team members too. Then to help you manage everything, GitLab offers permission management, such as user roles and their level of access to change your code. So most of the things you've seen on the previous slides are what you would expect to see, but as I mentioned, GitLab is an integrated set of tools for the full software development life cycle. So we've built a number of great features and workflow best practices right into our product. We are for a built-in continuous integration and deployment system which tightly integrates testing and deployment into your workflow. We also offer a built-in container registry to store container images. Now let's see how these tools take you from idea to production. Over to you, Mark. Thanks Rebecca. At GitLab, our goal is to offer a product that can take you all the way from your ideas and the earliest stages to actually shipping them in production. We've broken it up into these 10 steps and traditionally you'd have many independent tools to do this. Several months ago, our founder and CEO, Sid, put out a public challenge that we would ship in a single package this entire workflow so that everything you do, you can do within GitLab and that we'd ship it by the end of the year. I'm ecstatic to say that at the end of 2016, with the 8.15 release of GitLab, we brought this vision to reality. For the idea stage, we believe a lot of ideas come from chat. So we have a chat client, Mattermost, that ships with GitLab's Omnibus installation and we recently integrated both Mattermost and Slack for chat commands. Then we have GitLab Issue Tracker and we recently released GitLab Issue Board for planning. For coding, we have our online file editor but now with 8.15, we have a new web terminal which I'll show you later. For committing, of course, we've got GitLab repositories. For testing, we've got GitLab CI CD for continuous integration and testing and container registry. For review, there's merge requests and recently we added review apps to see a live preview of merge requests. For staging, the lab CI CD has been heavily extended to include continuous delivery. For production, we support continuous deployment with GitLab CI CD and we now have chat ops integration with Mattermost and Slack. For feedback, we recently launched Psychoanalytics and I'm really excited to announce we've started bundling Prometheus for monitoring in GitLab 8.16. Now onto some highlights of the 8.15 and 8.16 releases. We want everyone to quickly get a fully functioning CI CD pipeline that deploys to a container scheduler. It shouldn't require any effort to get started but it should also be scalable and not hide any of the magic. Auto deploy does this. Auto deploy adds a single button to your project that when clicked will create a merge request with a template that will automatically deploy your application using Docker to your container scheduler. The cool thing about this is that this immediately leverages review apps, meaning you can see it working before even merging the merge request. This is as close as you can get to one click deploys while exposing what is happening and having all of this be version controlled ready to collaborate and iterate on. In 8.15, we shipped auto deploy with a template for deploying to an OpenShift cluster and in about 16, we added support for Google Cloud's Container Engine or GKE which is a Kubernetes platform. Up to the hood, we use Docker or if no Docker file is present, we use Heroku build packs to package up your application into a Docker image that then is deployed to Kubernetes. We wanted to add support for more container schedulers and cloud platforms later such as Mesos and Docker Swarm but contributions are very welcome in our temporal post tray. Working together with your container scheduler, GitLab happily spins up several dynamic environments for your projects, be that for review apps or for staging or production environment. Traditionally, getting direct access to these environments has been a little painful and that's a shame, it's very useful to quickly try something in a live environment to debug a problem or just to experiment. With the web terminal which shipped in 8.15, this becomes extremely easy. Just visit the environments page in your project and click on the terminal button. GitLab will SSH into the instance for you and allow you to tinker away. We've previously shared a webcast with an extensive vision for making world-class monitoring easier for everyone. And with GitLab 8.16, we have taken our first step towards that goal. In this release, we have included Prometheus and its node exporter as part of our Omnivus package. This will provide high quality time series monitoring of your GitLab servers resources. Both Prometheus and node exporter are off by default for this release, but we plan on having them on by default studying with GitLab version 9.0 that is scheduled for March 22nd. For now, simply enable the features and reconfigure GitLab. After you have enabled Prometheus, you have access to the Prometheus console or you can connect to a compatible dashboard tool such as Grafana. Now this is just the tip of the iceberg in the coming months, we'll be adding monitoring to auto-deployed apps. So you can see performance charts for your own apps right inside GitLab. Okay, that's enough time to talk. Let's jump into a demo here. Start screen sharing. Okay, looks like it's up. So here I'm going to show off auto-deploy, terminal and Prometheus monitoring all running on a fresh installation of GitLab on Google Container Engine. It actually takes several minutes to spin up a new cluster. I've already gone ahead and spun it up on Google Cloud Platform under the Container Engine section. So here's our new cluster. I don't know what I've made for the demo. Pretty straightforward. I've actually followed the instructions in this Guveni, Guveni, a GitLab demo repo here. It's really straightforward, it just does take several minutes to go through, especially the first time. But basically it's all there, no magic involved. And here is our Guveni's dashboard showing off the pods that we've created for GitLab. So now I'll switch over to the GitLab instance itself and I'll start from really creating a new project and just create a really simple project here. I'm going to import an existing project I'll make this one public, second import. Again, this is a really, really trivial project. Now I'm not saying to here just a little bit of a two file, Dr. File and the single Ruby file. The first step here is I'm going to configure this project to talk to our Guveni's cluster. Activate this and first step is to get the UI URL. You grab that actually from the cluster itself and then now I need a token and certificate and I grab that Guveni's dashboard, click save and I'll just click test just to make sure. Great. So that's it. Now that we've set up Guveni's, see on the project there's this new button here called set up auto deploy. I click on that and I pick Guveni's from the dropdown and I get this CI CD configuration script. It's fairly long, pretty straightforward though and luckily everything's configured for you. The only thing I need to do here is change the domain for all of my apps. Great. So we see that it's actually kicked off of a pipeline run. The ICD is already configured for this because of this auto deploy and in just a couple of minutes it'll actually finish and watch the progress see if the build is actually finished already now creating the review app, right? And there it's done. I see now that it has created this review app. I click here, I can actually go and watch. Wait a second. It will actually finish but it did take a little while for the container to finish, to finish it, can't figure it. All right there we go. Hello world on the review app all done automatically, very few clicks really, really straightforward and just to make it a little bit more interesting we can go back to the review merge request and we actually see that from the merge request itself it tells me about this deployment and he can give me a link directly there. So anybody else who's reviewing this merge request who wants to look at the code but then also see it actually running can just go click on there. So really great feature, I'm really easy to get out. So that's auto deploy. Now let's take a look at terminal. We go back to this. You see that there's a little button there. I click on that and I get connected to that to the running instance. Here I can see our files there and I even want to make some changes. This is actually worked back to there. Here we go. I just updated the change on the terminal itself and went and updated that app and now it's running and changing and showing the updates. So great for tinkering around. That's a great production stuff. I mean, this is inversion control. Of course you want to go back and put that back into version control but if you just wanted to fix a little quick thing and see how it ran without having to pull up everything locally, it's a great way to get started. So now that's terminal. Last thing I wanted to show off was Prometheus and here is the Prometheus console for that for GitLab itself. For security, if you're really observing here and notice I'm on localhost, for security purposes, the Prometheus server isn't exposed by default on this configuration. So I've actually set up port forwarding from the convenience cluster to my localhosts 9090 just so I can see access on that. All right, here I'm just going to copy and paste a quick query and pull the graph and so we can see for the last hour what the CPU load was. Obviously it was pretty idle while I wasn't doing anything and then we started doing the demo and load kicked up a little bit and I'm going to copy and paste another one here. Memory usage, same thing but basically memory bumps just a little bit while we started using it. So great, great start here. Prometheus is an awesome tool, lots of traction in the industry and we're really excited to have it be part of GitLab here. So that's it for the demo. We just take it away. Thanks Mark. Let's now talk about another exciting feature, time tracking. So time tracking was released in 8.14 as a beta feature for the enterprise edition. Time tracking lets you record, estimate and time spent on issues and merge requests. This is a horrible reporting tool as well as a good planning tool. Since the introduction of time tracking, the usage of this feature on GitLab.com has been massive. Moreover, we've received a lot of feedback about the fact that time tracking could be used by companies of all sizes and not only for companies with more than 100 employees. For this reason, we decided to bring time tracking back to see the community edition. So it is now available for everyone. And by the way, if you want to see how time tracking works, you can rewatch the webcast for 8.14 where we demo it at length. But there is another thing we have brought with this release about time tracking. We've added an API to time tracking. So from now on, everything you can do in the UI can be done with the API. All the new API methods are in the documentation so feel free to take a look and do awesome stuff with it. And by the way, if you do create integrations for time tracking, let us know because we'd love to hear about them. In 8.16, we've also improved a popular feature, the merge request approval. Merge request approvals have been around on the enterprise edition for a while and they've just received some love in our latest release. The merge request approvals mechanism is simple. You can define a set of approvers for merge requests that are submitted. You won't be able to merge this merge request unless all approvers have given their consent on the work done. But until now, once the approval was given, there was no way of undoing the action. There is now a handy button that lets you remove your approval if you've given it. And as an added bonus, you now also see who have already approved a merge request. What else did we ship in 8.16? Well, we've launched a new way to search and filter issues. The interface is more intuitive and natural. And more importantly, this change will serve as a foundation for the future iterations with plans for this search bar. You can now be more in control of how your organization uses GitLive CI-CD with the ability to limit the usage of shared runners by limiting the build minutes per group. Another cool feature, you can now use slash merge in a comment or a merge request body to merge the merge request automatically. We've also received a great number of contributions that we've added to the community edition this month. For instance, deploy keys can now have right access. There are no changes on your current keys. Moreover, by default, all deploy keys are redone it. Another contribution is to show the last two days of your SSH key in your account. That's super handy. Finally, we now display how the space of your project or your group is used. Before, we indicated the total storage regardless of what it contains. Now, we can use the details with how much space the repositories, build artifacts, and LFS take separately. That is for a new review. We've added a lot of other small details and improvements here and there, so I invite you to read the blog post to learn everything about 8.16. And what about upcoming features in the next releases? First of all, we bring squash commits and auto rebates for merge requests. This is a highly requested feature and we are pleased to announce that it's coming soon. We'll also give more love to issue boards. We think issue boards are a very valuable tool to plan your project and we think it has a lot of potential. We'll introduce features that change our teamwork when cheating software. One of these features is the ability to make sure you don't merge code that contain external dependencies with licenses that can be harmful to your project. For instance, you will be able to prevent adding dependencies with copy def licenses. We also want to provide better audit logs and events. That way you will be in control of what the users do in your GitLab installation. And we also introduce on March 22nd, GitLab 9.0, which we talk more about in the next release. And finally, let's very briefly talk about our vision for the first quarter of this year. So in 2016, we've completed our vision that we call from ID to production. We've dramatically simplified what it takes to have an ID and goes through all the steps required to cheat these ID to production, all in one tool. We are very proud of this achievement, but we also know that it's still somehow difficult to set up a news. For a Q1 of this year, we want to allow everyone to be able to replicate it by simplifying the entire process. To hear more about our plan for 2016-17, watch the video made by Jobe, our VP of products in the link indicated in this slide. And now back to you, Rebecca, for a round of questions. Thanks, Regis. Now is your opportunity to ask Mark or Regis any questions you have about these features or the latest release. But I'll kick things off first with a question for you, Mark. In your demo, you showed us how to use auto deploy with Kubernetes using Google Container Engine. Would this work on any Kubernetes cluster? Yeah, Rebecca, thanks. That's a good question. So the auto deploy template should work for any Kubernetes cluster there. But the demo repo that I showed you with the instructions, that's all written specifically for GKE and relies on a couple of the G Cloud functions. But basically, it shouldn't be that hard to translate that to any Kubernetes cluster. We're not relying on really much more than just authentication and things like that. Whereas previously, we had an OpenShift version which definitely did rely on OpenShift to do a lot of things. We've taken control of that and then we built it all in. So it should work pretty well with Kubernetes, but you may have to change the instructions a little bit. If it doesn't matter, please do comment on the project itself if you do run into any problems with your own type of cluster. We'd love to help everybody learn from this and make sure that it does work on every Kubernetes cluster. Okay, thanks for that. I've got a question from Patrick. He wants to know if there are any plans to add some configuration management. Is currently there is very good workflow for development but not for configuration management? So that's a good question. We definitely have a lot of people using GitLab for configuration management. So a lot of people would argue that it does everything today. Clearly a lot of our effort with the CI CD has been around actual code and configuration management. But the CI CD configuration, the GitLab CI YAML file is under version control itself. And so as much as you leverage GitLab CI CD for your configuration management, that is all version controlled. If you have other suggestions for features or improvements to the workflow, we'd be happy to hear about them. Best way to do is create issues on GitLab CE and we'll follow up on any individual ideas. Thank you. Daniel would like to know, he says, GitLab has been adding great features for web developers. Can we see how some of these tools can be used by embedded developers? That's a great question too. Clearly a lot of what I've shown there is most tuned for web development. The CI side of it obviously works across the board. You can compile any embedded language or whatever. It's all fine. The CD side, it's probably a little less so we're not automatically going to be deploying or spinning up review apps or anything equivalent in any kind of embedded software world there. That's again a scenario where if you've got ideas we'd love to hear them. Our focus has been on the web developer for continuous deployment. But depending on how you're using it, some of those pieces will translate over but not everything. Okay, Patrick would like to know, is the file locking feature coming to the CE edition? Thanks Daniel for the question. So at this point, no file locking feature will remain in the enterprise edition and perhaps it's a good moment to very briefly talk why. That's because we'd love to give everything to the community edition but somehow we still need to have some value in our enterprise edition offering in order to sustain the development actually of the community edition, right? So because we still need to generate some revenues, right? So for this reason, this is the kind of stuff that will remain in the enterprise edition. Okay, Pascal has a question about squashing and rebasing. Is that coming to the community edition? So it's definitely related. At this point, squashing and rebasing is scheduled to be available on the eSparter edition for the same reason. Patrick has another question. Is it possible to enrich the milestone feature like the issue boards? Thanks Patrick for this question. Definitely, we still like the milestone feature and we haven't put much more emphasis into it at this point but we will in the future. For instance, we have two things that we want to do in the short, medium term. It's bringing a burn down chart to milestones which I think people will love and also add some kind of reporting to it. For instance, with the introduction of time tracking we could leverage all the data that we have about time tracking and put them on the milestone and have some kind of nice reporting with that. So this is what we want to do in the future for the milestone. One of the kind of things that we want to do in the milestone view. Okay, Mario would like to know if there are any plans to integrate with Rancho? So we don't have any plans specifically yet. I've been following a venture a little bit and I'm kind of impressed with what they're doing. And we happily support, anybody who wants to submit a contribution there but we'd be mostly looking for them to support that and add capabilities. At the moment we are focused strictly on Kubernetes is just we've got to have some focus. And we want to do a great job with that before we really look at expanding into other solutions. Okay, Machik, I apologize if I'm not pronouncing your name correctly. Machik would like to know if there are, sorry, I've lost it. Are apps deployed using auto deploy production already? That is, do the templates support multiple app replicas for HA? Yeah, so that's a great question. Production ready is something you've got to define yourself. I wouldn't go so far as to say that these auto deploy apps are going to be production quality for everybody. I think of it sort of probably more like a Heroku level. You can have multiple servers and containers with spin up and things like that but is there automatic failover and things like that? No, definitely not. So it's or maybe you call it for small production apps but I'm sure you'll want to build from there with your own best practices and what you would really want for your real app. Okay, Michael would like to know is it possible to view a time tracking overview for multiple repos or projects? At the moment, no. The time tracking capabilities are only tied to the issues and the multi-quest themselves but in the future, we definitely want to offer this kind of stuff, right? So we have to start somewhere anyway because we are always trying to ship a very minimal viable product into the production. But in the future, this is the kind of stuff definitely that would be very interesting especially for a large group of projects or even large companies where they have multiple projects, multiple groups and I think the possibility to have an overview of all that would be extremely useful and this is definitely something that we are aiming to do. And for that, I suggest all people who are listening to go to our issue tracker for ERC but for E at the moment, this is where you'll find the time tracking features and look for the time tracking label and everything that we are planning to do in the future for time tracking or that is being discussed, at least, is here and Flicreet contributes to, at your point, to any issues that we have. We really appreciate it. Okay, we have a question from Elric. Are there any plans for supporting chat-ups over Microsoft Teams? Yes. We've been considering it. So there is an issue for that in the GitLab CE Tracker, issue tracker. So you can just look for Microsoft Teams integration and we are discussing this exact topic at the moment. So Flicreet, you also contribute. Okay, Charles asks, are there any plans to add templates for applications? Yeah, it looks like he added a follow-up. There are specifically deployment templates for, say, Django or Java Spring. So I guess there's two answers there. One is we've actually had CI CD templates for specific languages for a while. When you go, if you use the web interface and you go to create a new file or you click on configure CI, you can have a drop-down there with a bunch of different choices, different frameworks and languages and whatnot. You can just pick from that list. But in addition, the new auto-deploy template is kind of magical in the sense that it uses the Heroku build packs to automatically build several different language frameworks. So Ruby and Python and everything else, it will just auto-defect whichever one that is and compile it appropriately. So now with a single template, you actually get all of those different languages. But yeah, we do have language ones, earlier ones that were specific for different frameworks. Okay, we've got another question from Machik. How do you support database migrations when using auto-deploy? So that's a great question. Basically right now, there's no migrations built in auto-deploy yet. So you would probably want to edit your out-of-the-autos by script to put in migrations when you see fit. It's something we're definitely thinking about. It makes sense to have them, especially for review apps, any kind of database change, you'd want to be able to do that. It does spin up, you know, it'll load your seeds database or something like that. But yeah, you'll probably want to put migrations within yourself. Okay, we have a follow-up question from Daniel about milestones. He says, I would love to see milestones display issues like the issue boards, maybe as part of group-level issue boards filtered by milestone. Do you have any comments about that? Yeah, we actually haven't thought of it yet. So that's a nice idea that could be discussed, definitely. Daniel, either you go to create an issue about it in our tracker or I will do it after this call and we'll be able to discuss it. I think it's a nice idea. Okay, Vijay Gopal has a question. He would like to know about any option to add the deploy key to an entire group instead of a single project. That's a good question. I'm sure we have an issue on this. We don't have it off-hand. There's a lot of things we'd like to be able to do with a single project. I think that will just come in time. One thing to point out is depending on what you're using deploy keys for, we have changed the user model recently. So at least for GLEB-CICD, if you're doing things on the runner, runner now can do a lot of things on behalf of the user that triggered the pipeline. And so that means that if you've got sub-modules or if you want to pull down a new Docker image from a different project, as long as the person that triggered the pipeline has access to that project, whether it be group-wide or even on a different group, they will be able to do those things. Several months ago, you couldn't do that. So a lot of the things that people were using deploy keys for, you don't really need to anyway, need them anymore. Okay. Sorry. Sorry, I just thought you had a follow-up there about master-signing deploy keys. I know what you meant about that. But we definitely... We don't yet currently support master-signing or group level-signing, but I'm sure there's an issue. Please contribute if you want to see that feature in there. Okay. Any other questions before we wrap this up? Okay. I think that's it then. Move on. Thank you all so much for joining us. Oh, I just see another one's popped up. Charles says, do you have any additional under-filed users? That's an interesting question, depending on what you mean by that. There is already Git host. We have paid hosted GitLab, both CE and EE currently. So I'm not quite sure what this question is about. So specifically enterprise? Yeah, we definitely have plans to push EE more on to Git host. I think we're actually in the process of renaming it or maybe, but right now it's Git host. Right now it focuses on CE and EE is something you can talk to us about. We definitely want to be able to let people have EE hosted and any size would be supported then. Okay. Last chance. Well, if there are any follow-up questions, you're very welcome to post them in an issue or we will be making a recap of this webcast and recording of it available on the blog. So please welcome to post questions on the blog post as well. Thank you all so much for joining us and for sending in your questions and for your feedback over the chat. It's been really great spending time with you talking about 8.16 today. Thank you all again and have a wonderful day. Thank you.