Apple developers in growing development teams invariably need a continuous integration system. This automates the build, analysis, and testing solution for software development using Xcode. macOS Server has an Xcode service, capable of integrating your developer account with git, providing many of the options required to build a continuous integration system. Before you configure the Xcode service that can take committed code and then test and build your software, you’ll need an Apple developer account. The Xcode service then links git to a developer account and runs automations, referred to as bots, in Xcode. Therefore, you’ll also need to have Xcode installed on the computer running the Xcode service. Bots are then managed and reported on using a web app that the Server app runs. Once the pre-requisites are met, open the Server app and click on the Xcode service. Click on the Choose Xcode button. When prompted, browse to the version of Xcode you have installed on the server. Configure the user account to use for the service. The service will then require you to login. Do so when prompted. This enables the user account, which you will then need to login as. You’ll see a new user environment. Use fast user switching to then switch back to your other account. Xcode will require access to the Accessibility framework to run unit tests. Click on Request Access to provide the rights to Xcode to do so. Once access has been granted to Xcode, you’ll see the version indicated in the Build Using field. Next, click on Add Team, in order to identify the correct team from your Apple Developer account that will have access to the Xcode service. When prompted, select the team from your Apple Developer account that you wish to provide access to the server, note that you need to be a team agent or an administrator of the developer organization. Click on the Repositories tab. Here, you will define repositories for your Xcode projects. Click on the Repository Access button to define what protocols git should be accessible via. At the Repository Access screen, select HTTPS or SSH. Click OK. Click the Edit Repository Creators button. At the Repository Access screen, add any groups of users that should have access to create new git repositories. Once all of the appropriate users or groups have been added, click on OK. Select your repository again, and click on the HTTPS Access button to provide access via HTTPS. Once saved, double-click on the repository again to see the uri for each type of access. And that’s it. Next, you’ll want to add a repository to the Xcode app. To do so, open Xcode and then use the Source Control menu to select Check Out. From there, you’ll get a Check Out screen. At the Check Out screen, enter the uniform the repository screen, shown in the previous step of this article and click on the Next button. Next, you’ll need to create bots to automate your build process.
I’ve done a few articles in the past on different tasks in svn and git, but I have a little cheat sheet of sorts I’ve been using for awhile for Subversion on Mac OS X and thought I would share it. Before you get started, check your version. I use 2.0 but I seem to remember all of these are about the same as they were previously:
svn --versionTo get started, Subversion uses a repository to store projects. Each client needs a repository and these should be on direct attached drives. The repository hosts a Berkeley database a folder per project you check out, or import. To create a repository in a folder called Repository that lives in your home folder, you can use the following command, which uses the svnadmin command (svnadmin is used for most admin tasks in Subversion and the svn command itself is used for most user operations) and then the create verb, followed by a path:
svnadmin create ~/Repository
Note: These commands are mostly the same in Windows, except you use a drive letter rather than a fully qualified path. They are identical in Linux.Within the Repository directory, each project will have a folder. Within these, you would then create folders for branches, tags and trunk, where trunk is the directories and files you will be working with. Then, we’ll import our first project. To do so we’re going to use the svn command, along with the import verb and then in the second position, we’ll use project to define the type of import. Next, we’ll define the location. The location could be http:// or file:///. In this case we’ll use an existing, mounted AFP file system at /Volumes/myserver/sharedrepo/projectname. Next, we’ll just put a message in there using the -m option, indicating “Initial Import”:
svn import project file:///Volumes/myserver/sharedrepo/projectname -m "First Import"That wasn’t so bad. To see a list of the projects stored in a repository, use the svn command along with the list verb. When I do this, I like to use the –verbose option (optional, thus an option). YOu would also provide the path to the repository:
svn list --verbose file:///Users/cedge/RepositoryTo update the repository:
svn updateWe now have a local copy of the project we imported earlier (creatively called projectname) and can work on it. Before we start working on it though, we want to check it out. To do so, we’ll use the svn command, along with the checkout verb. We’ll then provide the path to the project and name of the project:
svn checkout file:///Users/cedge/Repository/projectname/trunk projectnameWhen you’re done working on things, let’s look at what’s changed using svn’s status verb (btw, a writing point, by making svn possessive there, did I give it a personality? If so, then it’s certainly cranky at times so I suppose that’s fine):
svn statusYou’ll invariably want to add things to a project, which uses the oddly named add verb (bad grammar pun, sry):
svn add filenameRemoving files is a similar process:
svn delete filenameAdding, deleting and changes all need to be committed once you’re done working on the project. To commit changes, use the commit verb. Here, we’re going to provide a message explaining what we did (Added a method for handling invalid file names and bad grammar puns) and then the path:
svn commit -m "Added a method for handling invalid file names and bad grammar puns" file:///Users/cedge/Repository/projectname/trunkI didn’t include tagging, getting releases (list verb), using preshared keys (ssh-keygen, ssh-copy-id, ssh-agent, ssh-add), resolving conflicts (resolved verb), so feel free to add comments with your examples if others read this and would like to add more!
To make a Subversion backup (replacing /repositorypath with your actual repository path and /repositoryname.dump with the path and name of the file you would like to export your repository into):
svnadmin dump /repositorypath > /repositoryname.dumpTo then restore the Subversion backup (replacing /repositorypath with your actual repository path and /repositoryname.dump with the path and name of the file you would like to export your repository into):
svnadmin load /repositorypath < /repositoryname.dump