Good afternoon everyone. Welcome to Continuous Integration in Xcode 5. My name is Andrew Nesbitt. I am the engineering manager on the OS X Server part of this feature. So as you heard in yesterday's platform kick off, the theme for Xcode 5 is building better apps. And Xcode 5 is packed, full of amazing new features to help you share this goal. In this afternoon, we're going to spend our time looking at one of those new features in particular and that is of course Continuous Integration. And hopefully you will learn how you can use Continuous Integration to build better apps.

So the lineup for this afternoon is that we will start out with a little bit of a terminology refresh of the some of the key Xcode terms that we need to know. And after that we'll dig right in. We'll start exploring the Xcode Service and we'll talk for a while about configuring OS X Server for Continuous Integration.

After that we'll do a deep dive into Xcode 5 and the band new bots feature that we have. And then we'll spend some time looking at the web application and the feature that we call Scoreboard. And after that we'll finish with some best practices that we have learned inside Apple for deploying the service.

So the big question is why use Continuous Integration? Over the years, through many iOS and OS X releases, we have given you an enormous toolbox of features to use. And you guys have definitely arisen to the challenge by shipping amazing applications. And of course, shipping amazing applications we all know requires testing. And as the number of OS versions that you target and the types of devices that you target skill it becomes more and more difficult to test your applications well. And this is where Continuous Integration comes into play.

Continuous Integration will give you the opportunity to do testing on multiple OS versions and multiple hardware models. Of course, once you have a server in the mix, you're now in the position to build, analyze and test your project often. And of course, having a server will give you the opportunity to catch problems quickly and this is the key automatically.

Many of you have more than one Mac and I'm sure a lot of you have a Mac sitting in your office doing nothing. And this is a great opportunity to put that Mac back to work. Let the server do the heavy-lifting of building your-- building your project automatically. And having a server lets you do things that you can't do in Xcode or that you can't do in Xcode feasibly and the big thing here is the ability to gather, build, and test history for your project over time.

And, of course, having a server in the mix gives you an awesome new way to distribute builds to your team and I see some examples about coming up. So to get started, let's talk for a little second about some terminology that you're going to need to know. There are three key terms.

Number one is that of a scheme. And a scheme is a very simple concept; it's just a recipe for building your project. A scheme defines what targets you're going to build, what dependent targets you're going to get built, and also what build settings will be pass when those targets do get built.

And because we're dealing with the server, a server needs to have access to this scheme information. And schemes are typically personal things, I'm sure you all have a bunch of schemes that you set up just the way you like them. But we're going to use a little extended version of the scheme and that is of a shared scheme.

And a shared scheme is nothing more than a scheme that has been checked in to your source controller repository and shared with the rest of your team. So that's item number one. Number two is that of a bot. And a bot is a configuration for analyzing, building, testing and archiving your project on a schedule. And we'll come back to this guy in a second.

The third item of terminology is that of an integration. And an integration is just a single run of a bot. So every time your bot runs, your bot is said to be performing an integration or it is integrating. So let's look at a little bit more detail of surrounding bots.

So like I said, a bot is a configuration for building your project. A bot defines what we're going to build. So there are two things here. Firstly, it defines where the source code lives that we are going to build. So what repository that source code lives in? How are we going to access that repository to get that source code? And secondly, the project or the workspace inside that SCM location that we're going to access where that project lives? Secondly, a bot defines when we're going to build it. So we have some great scheduling options in the Xcode Service.

We have periodic options so you can build your project hourly, daily at a time or weekly on a day at a time of your chosen. We have on-commit options. So you can build when your source repository changes and you can tell the server when your source repository changes by a heap script.

Or you can have the server periodically checked with your SCM server when your source code is available, otherwise known as pulling. And of course there's manual. So you will-- this will be you will run the bot when you feel like running the bot. The third slice of the bot configuration is that of how we're going to build your project.

And this is composed of the shared scheme information that you've defined when you set up the bot, which scheme you'd like us to use. And then some options, we have some action options available for your bot. So you can choose whether or not you would like your bot to perform static analysis, whether or not you would like your bot to perform testing.

And if you are performing testing, which devices on which you would like to perform testing. And we support bot testing on the Mac which is the server. We support testing on simulators, we support testing on a single device, we support testing on multiple devices or any other combinations of those settings. Where that makes sense? Of course.

And lastly, your bot can define whether or not you would like us to produce an archive. And an archive will produce both a package and an .xcarchive file for a Mac project or an IPA on an .xcarchive file for an iOS project. We also have some great notification settings for the Xcode Service. So when you set up a bot, you got a couple of options.

So we let you notify people, we have checked in code to that bot so all the source controls submissions that have been made since that bot last run, all those people can get notified and you can choose whether to notify those people when the bot is successful or when the bot fails. And you can also define lists of e-mail addresses for people you would like to e-mail on those conditions as well.

So the Xcode story can really be thought of-- the Xcode Service story can be thought off in two parts here. So there is OS X Server and we have an amazing preview releasable OX X Server, and of course there's Xcode 5. So let's start by digging in to the OS X Server part of the story first.

So in the Mountain Lion timeframe, we made server an application. No longer a server, an entirely separate operating system that you have to set up, Server is just an app that you purchase and download and install from the Mac App Store. And it's never been simpler to turn your Mac into a server. And carrying on this theme of simplicity in the next version of Server the pre-release that we have available. We have some great new features. And one of those is simple setup.

Simple setup takes out all the complexities setting up your server. No longer will you be asked a bunch of complicated questions about networking configurations or Apple ID configurations, you're asked one question that is an administrator user name and password. And once you've entered that credential, the Server is up to the races setting itself up and within seconds you have a server available and ready to be used.

We also have some brand new UI in server. Server looks great, it's never look better and we're actually servicing some really useful information that we find that people really, really want. Like how your service is behaving, how to access your service and whether your service is on or off.

So as an example, let's dig in to what it takes to set up an OS X Server. So when you launch OS X Server, you'll see this. And this is the Welcome menu for the application. And when you click Continue, you'll be asked for a user name and password. And once you type those guys in, the Server goes off and starts doing its thing.

And very quickly you're launched into the OS X Server application. And in the left you'll see all the services that the OS X Server application supports. And on the right, you'll see the detailed view for those services. So before we go any further, you're probably all wondering about the thing that you're here-- you're here to hear about which is the Xcode Service.

The Xcode Service when it's turned on in OS X Server will start advertising itself across your network and it uses Bonjour to do that. So any Xcode 5 user that's sitting within your network will see servers that are available-- that have been available, made available in your network. Once the service is turned on, it's super simple to create and manage bots that build both Mac and iOS projects. And if you're a little bit fuzzy about Access settings, we do have some great ways to configure that too.

You can define both who you would like to be able to create bots on your server and also who you would like to be able to view bots on your server. And you can set this up in whatever way that you like, whatever way that makes sense for your team.

We also have some really, really great integration with the Apple Developer Program. And this means that you can join your Server to your existing Apple Developer team. And the question might be well why I would I want to do that? And the answer is when your Server joins your team, your Server has the opportunity to request its own Mac and iOS signing identities and also download all of the team provisioning profiles that exist for your team. And this puts us in a great position. And this brings me on to my next point which is devices. OS X Server has great support for devices for bots. So once your server is a member of a developer team, you'll see devices in OS X Server.

You can easily add and remove devices both to and from your team and of course once you've done that, those devices become available when people set up bots using Xcode 5 against your Server. Another feature that we've been asked for a lot in OS X Server for the last couple of years is source control hosting and we are adding this feature too. So, OS X Server will support Hosted Git repositories and once they're set up with just a few clicks, you'll have a Hosted Git repository that's accessible by SSH, HTTP or HTTPS. And equally you can lock that repository done just the way you like it to.

And of course, if you're not ready to make the move to hosting your source code in an OS X Server just yet or you're using an external source control system like your hub, then OS X Server will equally well connect to those repositories too. So, we can connect to remote SVN and remote Git repositories and we can connect to those repositories anonymously with username and password or with public, private SSH key pair authentication. And it's really easy to set that up too. So, as an example, let me take you through what it takes to set up the Xcode Service in OS X Server.

So, when you go the Xcode Service you see this, and this is the Xcode Service panel and it's split into two parts. On the left is everything to do with bots and configuring your service and on the right, the second tab is everything to do with hosted repositories and remote repositories that your server can connect to. So, let's say we want to add our server to our development team, what does it take to do that? And it's really easy.

So, to do that, we click the Add button right here and we'll be asked for username and password. And the Server will go wide to the Apple Developer Program and figure out which teams this Apple ID is a member of. And because I am just a member of one team right now, I'm getting this sheet which says, "It looks like you're a member of a team, would you like to join your server to this team?" But if you're a member of multiple teams, let's say you're a contractor then you'll get a list of all the teams that you're a member of and you can join your server to one or all of those teams. You can have as many teams as you like with the OS X Server.

Once you've added your team, your server will set itself up and you see that this server is not a member of that development team. The next step of course is adding some devices, and once you plug in devices, devices are able to be used for bots. So, the server is recognized here that this device does not have a development that's set and this device is not actually enabled for development for my team yet.

So, I'm going to click on Use for Development right here and the server will quickly and easily add that device to my team. And as an example, we do support source control hosting like I said and here's what it takes to set up some hosting repositories. So we can either host it or remote repository and you see some more of this in our demo in a little second.

So, that is the OS X Server part of the story and of course there's the Xcode 5 part and this is where it gets really exciting in my opinion. Xcode 5 is an incredible release. If you have not downloaded Xcode 5 yet, I suggest that you go and do so immediately, it's really great.

And one of the nicest features I think in Xcode 5 is the Testing Edition and the new Continuous Integration service. So, as you go along with the theme of Continuous Integration in Xcode 5, there are a couple of things that I'd like to draw your attention to. Firstly, we have some great new kind of preferences. So, it's really easy to add an OS X Server to Xcode 5. You open the Preferences, type in the username and password or choose guest if your server administrator set it up that way. And you can quickly add your server to your Xcode.

Once you've done that, you're in a position whereby you can create bots for project and workspaces that you use in Xcode every day. Once you create a bot, the bot show up in the log navigator and you see our beautiful reports for Build and Test history. And these reports are not just reports, these are fully live interactive reports that have great assistant editor support.

So, you can select things on the left in the report and you'll see the source code that caused that error issue or test failure right on the right in the assistant editor. And of course, this affords you to dig in to your issues, or errors and you're wondering to write where they're happening too. So you see things going wrong in a bot and you can play with the source code and Xcode.

We also have great multi-device support in the Xcode Service and we have some really great UI in Xcode for looking at those results. You can see your test results overtime on across multiple devices for your bot. And for each integration that happens in the server you'll also see full commit history for all of the commits that were included in that build. And you'll see all of the log files that you're familiar within Xcode today be produced on the server and sent down to the client.

You have some great ways to view download -- view and download archives of your project right from within Xcode. And we also have some really nice source control integration that you'll see in our demo coming up. So to do that, I would like to invite Brent Shank who is a software engineer on the Xcode team. To come up here and show us the Continuous Integration service.

Thanks a lot, Andrew. Well, I'm really excited to be up here today, not just because I had five espressos this morning but because I love this stuff. I love unit test and I loved it for the first time this Continuous Integration System that just works. I don't know about you but I spend a lot of time dealing with some-- the other systems that are out there.

And they're great but they can be hard to set up, they can be hard to maintain, what we've done is super easy to set up, it's super powerful. Let me show you what it looks like in Xcode. So, the first thing we have to do to get Continuous Integration working on Xcode is we have to tell Xcode about an OS X Server that's running the Continuous Integration service, the Xcode Service.

I do that by adding an account for an OS X Server. And as you've heard by now, we have three types of accounts in Xcode 5. There's one for your Apple ID or Apple IDs, there's accounts for source control repositories, and of course there are accounts for OS X Servers. And I access those through the new Accounts preference pane.

Okay, well here's our beautiful new Accounts preference pane, you can see there, no accounts right now. It's really easy to add any of those three account types. I'm going to own account for an OS X Server right now. I click the Add Server button. And as Andrew said, any server that's set up on your local network is going to be advertised via Bonjour and you can add it that way. You can also add a server by host name or IP, and that's really good idea if you want to able to access it from anywhere.

I'm going to select this one on the list. Click Next and authenticate and here we go. So, I've added an account for server, it's really easy to do. You can add as many servers as you want, OS X Servers that you want here. So, what does this enable me to do? Well, we have some really tight integration of source control with the Xcode Service and Xcode 5. And part of where we surface that is in the new checkout workflow.

That's available in the Source Control menu. I go there now, and I'll click Checkout. So, what's in this table here? Well, this is going to show me a repository for every source control account that I've added in that preference pane. It's also going to show me any Hosted Git repository for an OS X Server that I have an account for. So as Andrew mentioned, this is the new feature in OS X Server that it can Host Git repositories. And you can see here, these are all repositories that are on that server that I added.

I'm going to select BubbleGum, click Next, it's going to authenticate and checkout. So that's a really great way to get source code for your team. So, let's see what the state of this project is like. I'm going to build it, and build failed because I need to switch to the simulator. I'll do that now.

The build succeeded, this is great, let's see how the tests look. I'll run unit tests, the simulator launches, the test are going to run, and will they succeed? They didn't, they failed. Well, this is good, this is what I wanted to happen. Well, how can we use Continuous Integration to figure out what went wrong? So I just checked out this project from source control, I didn't make any changes. So, this means someone else broke this test somehow. So, let's use Continuous Integration in bots to figure out what went wrong.

So, we surfaced bots from the log navigator. And you can see there a couple of things here that you haven't seen before in Xcode; Bubblegum and Bubblegum Nightly are both bots. You can set up as many bots as you want for projects, it's really easy to do. I'm going to show you the bot for Bubblegum. I'll click on that here. So, this is the bot report.

You can see it's really clean, it's really beautiful and provides a lot of great information. So, let's go from top to bottom here. At the top here, any time you want to run an integration, you just click Integrate Now. No problem. Usually, bots run out of schedule, you configure them to run manually, whatever you want, whenever you want integration, just click that button.

This button here, it will let you download an archive or a product that your bot created. And Wi-Fi let you install it on a device that's connected locally, that's pretty cool. And finally, on this menu over here, you can edit the bot, delete the bot, do other things with it.

And below that, in the status counts area, this shows you a high level status for your bot for the last integration that is the last run of your bot. So if there are any errors or warnings, you'll see that here. If you chose settle the bot from-- on static analysis, you'll see the status of that there. And if the bot is running tests, you'll see the status of those unit tests there.

Below that in the build history chart, you see the status of all the integrations that are displayed here and we show you as many integrations as we can show you. So, what you want to see here is you want to see there is a no issues line with the green checkmark. That means everything went well. You build bots and there were no errors, warnings or static analysis issues.

But if you do have some, that's okay, that's what this is for, they'll show up in this stock bars and these colors are obvious to you, warnings on yellow, blue-- static analysis uses-- are in blue and errors are in red. And I can click this bar, I can get a little more information about what's going on, and there's even a button that will take me to the integration summary for this integration.

Let's keep going down. The chart below here shows me the status of the unit tests for all the integrations that are displayed here and the goal here is to see these full high green bars. That means you had the unit tests, they run and they all run successfully.

Below that in the integration details area, this shows you all of the crucial information from the logs that were created when this bot run. So you made-- the only sub-- logs for the build and you may have logs for analysis issues or test failures if you configure your bot to do those things. What's really neat about this view is that it's fully integrated with all of the navigation that you used to in Xcode.

So what does that mean? I'll make my window a little wider here to-- so you can see that. So that means when I open the assistant editor which I do from the tool bar and this is where I get a left side by side editor view. The left editor essentially acts as the master editor when the assistant editor is in the Reference Files Mode. I can click one of these failures down here and Xcode will take me right to the source code where this problem occurred. So this is a really fast and great way to get to the heart of the problem.

So now we're using bot to figure out what went wrong. We see unit tests here and we can dig into the bot a little further to diagnose the issue. I'm pretty sure Andrew caused this problem by one of his classic late night integration sessions where he wasn't as careful as he usually as about checking things in. I can explore that a little bit more if I click the bar here-- that's never happened before.

This will jump me right into the Integration Report and you can see there are four tabs here. One of the tabs is the Commits tab and indeed when I go to that I see the Commit Log for this particular integration. And looks like Andrew is messing with me a little bit and he deliberately broke this field.

I'm going to go back and I'm just going to change this so I know that there are actually are five tea-flavored colors of Bubblegum here. So I'll just change this and I'm going to save and I'm going to check this in so we can run an integration and see what that looks like.

Fixing tests, commit. Okay. So while that's running, let's explore the bot report a little bit more and to close this is another. So there are two tabs, there is a Summary Tab that's we've been looking at and there's the Test Tab and this is a really great view because it shows you the history of the unit tests for all the integrations that we can display here. We can display a lot of integrations.

You saw this this morning, this is a really great view because it shows you at a glance how a particular unit test is doing and you can see most of mine are doing really well. I can filter this table to show me just the ones that failed and if there's a particular test that's been giving you trouble and you know its name, you might type that in here and filter the table even more.

Of course, over time, your server is going to build up history for thousands of integrations and you need an ability to go back and forth in time to check these things out. So you can see how this interesting trend line here where I had most of my unit test breaking and then they all got better so I can move the loop in this graph and I can slope just the integrations like here about. And these views also integrated with the assistant editor so I can bring it up again and when I select a test case, it will show me the source code for that particular test case.

I think that's really great. So let's jump back to the report for the integration. I can also see the latest integrations in the log navigator. I'm going to click this one here. Let's just explore this a little more. The Summary tab is very similar to the Summary tab for the bot itself. It shows you the high level status. It shows you the important integration details.

There's also the Logs tab and that shows you the exact same Build logs that you would see if you performed this particular bot run locally, if you perform this build locally. So this is really great. You can have the server storing these logs for thousands of integrations. You don't have to store them locally. Whenever you needed that data and you want to look at it, Xcode will download it for you and that's one of the great benefits of having a server that's performing your continuous integration.

But let's look at the Test tab. Starting this is the most exciting part of this feature. So what you can see here, there are four devices listed. They're actually all right here connected and what this means is the Xcode Service is running unit tests on all these devices. Now, think about this. There's never been a way to do this automatically before. There's never been a way for Xcode to run unit tests on multiple iOS devices at once.

And this is a huge deal. If you want to see how your product performs with iOS 7, for example, whether up on one of your devices, plug it into your OS X Server that's running the continues integration service and you'll get to see you get a high level overview of how your software is doing on that new OS.

I think that's very cool for people who have been writing in the test and have a lot of time and energy invested in them. This is going to immediately add a lot of value to them. And for those of you who haven't been writing in a test, I think this is a great reason to start.

And, again, this is all connected with the assistant editor so you can click Test Case and jump to the source code and do everything you would expect to do. So we've explored the bot report, we've explored the bot integration report, but what does it like to create a new bot? And to do that-- and I should create a new project. I'll show you what it looks like from the beginning. So, I'll put in an Xcode project, I would just create a simple iOS Utility Application-- I'll just call it Demo App.

So in this Safe panel here, you probably noticed for a while an Xcode 4 has offered to create a local GIT repository for this project and that's a really great thing to do. But now if you've added an account for an OS X Server in the Accounts Prep Pane, it will list any server here. And if I choose this server which I'll do and click Create, let me draw your attention to the Activity View up here.

What's going to happen is Xcode is going to create that local GIT repository. It's going to create the remote GIT repository and it's going to push it up to the server. So now you have the best of both worlds, you have a local GIT repository, your Scratch Pad and when you're ready to show those changes into your team, there's already a server that's backing up your data for you, you push those changes up there and your team has access to it.

This is really great. Okay. So we created a new project, let's create a bot. We do that in a Product Menu, there's a Create Bot item. So this is a new project so there's only one scheme. You probably have a few schemes in your project and in order for the bot to build your project, you need to share the scheme. We can do that automatically for you but-- and you should keep this check but I'm going to uncheck it so I can show you-- I want you to understand what this means. I'll show you how to do this manually.

I want this bot to run my unit tests whenever anyone checks in codes so we'll call that, I'm choosing the server here and I'll uncheck that particular button there. Okay. While-- We'll keep that checks since it will let me otherwise but I'll still let you know, help you out. I want this bot to run on Commit. Again, you have your choice here when you want your bot to run, and you can edit this at any time later.

And as Andrew said, you get to decide what you want your bot to do so of course your bot is always going to build your projects. So you're always going to know if there are warnings or errors, but these three other things are optional. You may or may not want your bot to run static analysis, to perform tests or to build archives. In this case for this bot, I just want it to run unit tests so I'll uncheck these two and we perform test action intact there.

I'll click Next, and because I told that I want to build-- to run unit tests, it's going to ask me which iOS devices I want it to run on. I have four here and I think they should-- the test should be run on all of those but you can configure this the way you want. I'll click Next and, again, so what happens by default when the build fails is anyone who committed since the last integration will get an e-mail but you can configure this however you want. So it's just a few clicks and we've created in a bot for this project.

Yes, the bot scheme needs to be committed. Exactly. So what this is all about? Well, let's go into the manage scheme sheet here for a second and you can see this check box is checked which is a good thing in this case. So I need the scheme to be shared so that the bot can build my product and my default schemes are not shared so that check box that I left checked in the Assistant, that's good but if you don't do that, you can always show your scheme into the Manage Scheme sheet here.

I'll click Okay and when I do that Xcode change to the files that are involved in the schemes so I need to commit and push those up to the server and you can see here in the Commit sheet there's these things related to the scheme you don't need to worry about what they are but you do need to do this in order for the bot field to run.

So I've committed those changes and I can force it to integrate now and you can see the integration has started. So really easy to create a new bot with the rich sourcing for integration that we have with these-- these two parts of this system that's why it's easy to get source control and get source code and to push source code back up to the server.

And I can see here, you can't see it but test are already running on these devices which is very cool. So with that, I'm going to give it back to Andrew so he can show you more about the web UI where we surface all these things to. Thank you.

You can connect to servers using username and password or as a guest. And once you've done that, the server shows up. And once you have a server, you're now in a position whereby you can check out the source code that's hosted on those servers. Xcode will automatically figure out what source repositories exist on the server and offer to check those out.

So we chose the Bubblegum, I'm going to check it out. And by clicking in the log navigator on the bot, we could see the bot summary report. And here you see all the beautiful test information for your bot. Along the top, you see so many kinds for errors, issues and warnings and test results. In the center you see summary grafts for your build history and your test result history. And at the bottom you see some integration details for the most recent integration.

Expanding the side bar you see each of the integrations that this bot has performed. I'm looking at the test results view, you see a beautiful graph of your test results over time for all of your integrations. And of course the best way is that we support multiple devices. So when you click in a particular integration and look at the test tab for bot integration, you'll see all of the tests split out by device. You could see which tests are passing, which tests are failing on which device.

And of course we have the assistant editor support as well. So when you're digging around in the test result table, you can see the information of the assistant editor on the right. Finally, Brent showed you what it takes to set up a new project and host out source code on an OS X Server. And with just a few clicks, it created a rebuild and it was on the server ready for him and the rest of his team to use.

So the last thing that I would like to talk about today is our web application. And the web application is really designed for everyone who's involved in the development process that's not necessarily living inside Xcode all day. And I'm sure there are lot of people that you work with that fall in to this category. There are localizers, there are testers, there are project managers if you're lucky or unlucky to have one. But the web application becomes a really useful feature for those people.

The web application will give you a view of your project outside of Xcode. So Xcode will only show you bots that are relevant for projects and workspaces that you currently have open. The server will give you a server-centric view of these projects. So you see a list of all the bots that live on your server.

And you can easily add and edit bots right from the web for all of the repositories that your server already knows how to talk to so those can be host of repositories or remote repositories that you've already connected up in server app. And once you click on a bot, you see the same beautiful reports that we have on Xcode.

One feature that's unique to the web application is the archive C and admittedly this feature that we stole from one of our internal systems. And this becomes the destination place for your tester in the morning to go and get a list of the most recent products or archive for your application.

So there's obviously archive in product downloading. But we have some really nice features too. There's build flagging. So you can flag a build as being a great build or flag a build as being a terrible build depending on your definition of being flagged. And of course we support build printing.

So if you know that you have a build that's sitting in your list that you maybe don't want to keep around or that you know was a particularly bad build, you can instantly delete it just with one click. And probably my favorite feature of the web application is that if you point an iOS device at the web app with one tap. You can install a build application from the Xcode Service right in your iOS device.

And then we have another great feature that we call Scoreboard. And you've all seen it I'm sure but I'll save that one for demo. So with that, let's look at the demo of the new web application and the Xcode Service. So here I am in Safari and to get to the web application you've got a number of options. Inside Xcode when you're looking at the bot we have a Gear menu and you can click on the Gear menu there's a handy link in there and it takes you right to the web app.

If you have a host name for your server and that may be, you know, a local host name for your server, you can visit that hosting and it will take you right to this web app. And also if you're in server app, we have a link that takes you right to the web app too.

So this is the bot list for the web application. And you'll see that we have an alphanumeric sorted list of the bots down the left and you see some great information for those bots. We see we have a number of bots here and a number of states. Some bots are succeeding, some bots are queued ready to be built, some bots are failing tests, some bots actually have catastrophic build failures right now.

Along the top you see some summary information for the bots that are running on your server. So the most recent bot that Brent actually just created in run, we could see it has zero errors, warnings, or analysis issues. The Bubblegum Nightly bot just kicked off and on the right you can see that we have handy download links for the Bubblegum bot too. So let's click on the Bubblegum bot and explore that in a little bit more detail.

So here you see we have the same reports that you see inside of Xcode. We have five great tabs along the top, they give you summary information, information about your Tests, information about your Commits, your Logs and of course the Archives page which is unique to the web application.

I can click around and just like in Xcode I can see the full test history for my project right here on the web browser. And I can scroll back in time just like in Xcode to select any range of test brought up that I'd like to explore a little bit more.

So you can see here that our project went through a particularly rough patch of having a lot of failing test and then we slowly brought that back in to zero again which is great. That's exactly what we wanted to do. We have the Commits tabs and the Logs tab which I'll skip over, and I'll go straight to the Archives tab because that's the most interesting part of this-- part of the web application. So the Archives tab is a time sorted list of the products and the archives for all the bots that live on your server. And each bot has its own Archive's page.

You can see that on the left we have some great flag icons. So I know that yesterday's build was a great build. We shipped the build for WWDC of the Bubblegum app and we know it was good so I'm going to mark that one as a flag build, such a great build. And also if have build here that I know that the day before yesterday was maybe not a great build. I can easily click the trashcan here and just delete that build with one click.

The other feature that we have in the web application is Scoreboard. And Scoreboard is designed for the big screen TV or spare monitor presentation of all the bots in your server. So if you have an open area in your workspace, like a coffee area or you have some space in your development and this is a perfect candidate for mounting a display in a wall and having some fun with bots. We do this at Apple and this is great. So there are two ways to get into Scoreboard.

First, I can click on the navigation icon right here and you can see we have a Scoreboard link. But we love Scoreboard so much that we give Scoreboard its own top level navigation item. And right here beside the Plus icon I can click on Scoreboard. And you can see this takes me into Scoreboard for this server.

So right now we have a number of bots and those bots are sorted by name. On the left you see we have a list of the bots and all their states and on the right we have a huge card with some great information about this bot. Along the top you see huge kinds for the errors, issues, warnings and test succeeds or fails. You see a list of the commits that contributed to that integration and we just cycle through those commits. And at the bottom you see the device information for the tests that we run for this button.

And as we cycle to the next bot, you'll see some information. And it looks like for this bot, a number of tests were run and at the bottom we have a bunch of devices on which those tests run. And it seems like Brent kicked off the Bubblegum bot just before he left the stage. And that bot just succeeded and we can see that that has one analysis issue and 27 passing test across the four devices that are connected to our server. This was great. So let's switch back to slides.

So that's the web application. The web application is designed for everyone who is not inside of Xcode including developers you may be away from Xcode at any particular time. You see the full list of bots that exist on your server and you can sort and filter that list of bots really easily. You see the same rich reports that you see inside of Xcode. And of course you can dig and drill through test history for your product just by scrolling a graft box three times.

And of course we have the Archives page. And the Archives page is a great way to ship builds to the rest of your team. Or to have one place the people and your team can go to every morning to download the latest build of your project. And, so these builds can be flagged or deleted at your choosing. And of course we have the Scoreboard feature.

And Scoreboard is great. I would encourage you all to set up a spare display in your development room or if you like, Brent and his bedroom. And, you know, have some fun with bot so that makes it really fun. So I did have some best practices that I'd like to pass on based on our internal usage of the Xcode Service with our small and large development teams.

The first is that if you're sitting in the audience here thinking yeah you know, this is well and good, this works great for, you know, the small iOS app or the small mac or the apps that are showing on stage or any app apart from my app, maybe your source code is structured in a weird and wacky way where you have to check out multiple nested copies of source code or you have multiple cross reference Xcode project files or you know, something pretty normal, then you'll be glad to hear that the Xcode Service actually supports bots that are configured against multiple source control repositories.

And the answer that I would have for you for that questions is to structure your code in workspaces and if you think about this, this is the best way that the server is going to be in a position where it can reassemble your source code in a way that we can build it the same way that you build the source code locally.

The second is more of a security best practice and that is if you are connecting your OS X Server to existing remote repositories with SVN or Git repositories, I would strongly encourage you to use role accounts for those repositories. That's just generally a good practice. You don't necessarily want to be entering your personal username and password onto the server and having the server check out code as you that's why role accounts were invented, they're really good for that purpose.

And also I would also encourage you to use SSH public/private key pair authentication and the OS X Server that makes it really easy to generate new public/private key pairs and with one click, copy the public key right to your clipboard so you can paste into websites like GitHub in just a second. The third best practice that I have is actually just some suggested bots. These are bots that we set up that we find to be really, really useful.

So the first of those is a non-commit bot and this one is fairly obvious one but if you think about it, you will have the supply in sitting in your office that's doing building, that's doing testing, that's running static analysis for your code base and running your tests for every source control change that's made and that's a really awesome feature. And if you have a slightly larger project, you can adapt this concept and say you would like to have a bot that's doing this work every hour or once a day, that's a really good thing to have.

The second is a Nightly bot, Nightly bots are great. Nightly bots can build and archive your project just in the same way you do locally and it will produce a signed Mac or a signed iOS Application that your testers can come in the morning and click in one link on the web app and download a build ready to be tested. So this is great.

And the third is if you are like my team, we recently switched to Git and we're a little branch happy right now so we branch for everything. And if you branch a lot then bots are a perfect candidate for branching. They're so light weight and it's a great way to continue to reap the benefits of Continuous Integration while you're using a branching workflow. So when you cut yourself a branch for a feature, create yourself a bunch of bots and you're ready to go.

So the next question is, how do you get these features? And I'm guessing a lot of you have already gone and figured this out but let's go through it just in case. So the best way is to go to developer.apple.com today and you're going to need three things. The first thing is you will need the preview list of OS X Mavericks.

After that, you'll need the preview the list of OS X Server and OS X Server requires some of the technologies that shipping is part of OS X Mavericks so you need to be running server on a Mavericks machine. And after that, you need to get yourself a copy of Xcode 5 and Xcode 5 will run happily on Mountain Lion and Mavericks and Xcode 5 will also run happily on the same machine or a separate machine from the server if you want to run a bot server locally, that's perfectly fine.

After that, you can join your existing ADC teams today if you're a team agent or team admin with no changes. Just enter your Apple ID and password, your server will join your team and everything is set to go. And, of course, once you've done that, your server will obtain signing certificates, special signing certificates for the server.

Your server will obtain provisioning profiles for all the devices that have been registered for your team and you can just plug the devices that you already have into your server and everything will be ready and just work. So you can quickly build iOS projects just by plugging in devices and entering your Apple ID.

So, in summary, I hope-- today you've seen that the Xcode Service and OS X Server and Xcode 5 is really designed to help you build better apps. It's super simple to set up and once you've set up these bots, you can build and you can catch build issues, errors, run static analysis regularly and importantly run your tests and run your tests on simulators on the Mac or run your test in single or multiple threaded devices to your server.

And the value of a server is really keeping history around for your project. This is not something that you can feasibly do locally when you're running Xcode, so being able to keep all the build logs, all the build products and all the results for your builds back through time is a really great asset for your team.

You'll be easily able to distribute builds to your team and the integration with Xcode is amazing. You'll have fully deep integration in the IDE with the Xcode Service and of course for everyone who's not living in Xcode, there's the web application and of course there's Scoreboard for the big screen television presentation of the stuff.

So there are a couple of related sessions that I would highly encourage you guys to go along and attend. So later in the week we have a dedicated testing session for Xcode 5. We'll be looking at some of the really great new testing features including some of the integration with bots and also there's a dedicated source control session later in the week too. So with that, I would like to thank you for you afternoon and I hope you have a good week.