iOS Continuous Integration Setup with CircleCI

hey cooker today you're going to learn how large iOS development teams work together to produce large and complex apps such as Instagram YouTube and Spotify now how do multiple developers work together on the same code base without overriding and destroying each other's code and how does a developer at his or her code without accidentally destroying some functionality in the app and finally how do you organize and keep tidy thousands of lines of code written by multiple developers while today I'm going to answer those questions and more so stay tuned hey there I'm Chris and welcome to code with Chris where we're going to teach you how to become a developer through building iOS apps now as a single in the iOS developer you can do some pretty cool things and there are a lot of successful indie apps in the App Store but on the other hand as a single developer you are limited by the scope and scale of the apps that you can build because at the end of the day we're all limited by the fact that we have 24 hours in a day a lot of the mass audience large-scale apps in the App Store are built by teams of people testers developers designers product managers you name it now how do all of these people work together to produce a single app well today we're going to look at some of the unique problems that teams face and how they overcome them but before we dive in I just want to give a shout out to circle CI comm who has the sponsor of this video they enable large teams to work together efficiently to produce awesome apps through their continuous integration and delivery services now these two processes are something that is very important for large teams to collaborate through and we're going to touch upon them later on but for now let's take a look at large team problem number one so how do multiple developers work together on the same Xcode project the answer is source control and in this case source refers to source code now there are many different source control management systems out there but one of the most popular ones is git and github is a popular choice for git repositories in the cloud now here's a quick rundown of how it works the git repository or git repo for short contain the master copy of the code the repo also keeps track of versioning of the code let's say it's version 1 right now when you want to work on the project you check out a copy of the code it's kind of like checking out a library book in this case you've made a local copy of the code this is also known as pulling the code another developer let's call her developer B can also check out the code and make a local copy on their machine you're both working on your local copy of the project and maybe you finish your work first let's say you have to fix a bug in the project and you nailed it the next step is for you to commit your code back to the master repo you can and should attach a message to say what you changed and why you changed it when you send your changes back to the repo the message you wrote will be attached to that change now this is known as committing or pushing or checking in your code different people will like to use different terminology now let's say developer B has finished her change and she's ready to check in her changes back into the repo as well but there's a problem because after you checked in your code to the repo you've essentially changed the master copy of the code and now it's out of sync with her local copy that she checked out earlier now developer B doesn't have any of the new code that you checked in so if she were to blindly check in her version back to the repo she would essentially be overriding your code luckily source control would detect that the master copy has changed since developer B last checked out the code so it's not going to let her commit her code developer B has to do a merge which involves getting the latest copy of the code from the repo merging it with her local copy fixing any errors that may arise from your code conflicting with her code and then after resolving any issues to commit the merged code back to the repo if you and developer B happen to work on the same file and same lines of code then there might be a conflict in which developer B needs to manually decide how to merge your code with hers now as you can see this merge process can sometimes get pretty complicated and you're gonna have to be careful not to overwrite anyone elses changes when you merge their changes with yours now imagine a team of 10 20 or 30 developers all checking out and committing code a source control management system makes sure that everyone can work on the same code base without accidentally overwriting each other's changes but to have so many people writing code also means that it's hard for one person to know the whole project inside and out and as a result any one developer might accidentally write code that introduces bugs into the app and this brings us to large team problem number two when a developer commits his or her code to the master repo how do they make sure that something isn't broken large projects can be thousands of lines of code so it's only natural that bugs can crop up unintentionally and this is where unit testing comes in unit testing is a process by which you write code to test your other code here's how it works you break down the code in your app into units that make sense let's say you have a chunk of code that creates user accounts now typically this code gets run after the user enters in their info from a form in the app but since you want to wait to test this chunk of code at will you'll write a test case this test case called a unit test will attempt to create an account with some dummy data now you can run this unit test and if it suddenly fails then you know that the unit of code that creates accounts is not working now imagine you write these unit tests for every chunk of code that does something in your project you'll end up having a suite of these test cases that you can run anytime you want to see if something in your project isn't working now it won't catch every single bug but it acts like a baseline and it's your first line of defense and once you write all your test cases and it's all set up you'll have an easy way to test that baseline now when a developer checks in some code you can run these unit tests as an easy way to screen if some baseline functionality has been broken as a result of that new code all right so you've got source control management and unit testing as tools to help large teams work together but here's another problem now just like handwriting every developer will naturally have a slightly different coding style so won't the code file that is written by multiple developers be really hard to read and this brings us to a large team problem number three how do multiple developer maintain a consistent coating style well first the team establishes a set of coding conventions or a style guide now this can be as detailed as saying if the opening bracket of an if statement should be on the same line as the if keyword or on the next line and it can also say things like how many line breaks should be in between methods in a class the more detailed you can be the more consistent your code base will be now in order to enforce these coding conventions across a large team there are tools out there that can scan the code and then I can tell you any lines of code which are not adhering to the style guide or the coding conventions that you set forth these tools are commonly referred to as lint or lint or tools now there are a lot of free lint tools out there and simply using one will ensure that your code base is tidy and consistent now we've talked about a lot of different tools but ultimately who is in charge of running these tools and a team well in the ideal case each developer would a make sure that before they check in any code into the master repo that they pull down the latest version and they merge any changes properly and I say properly because merging isn't always a trivial process I mean you're trying to merge your code with someone else's code that you didn't write and you have to take the time to understand what they wrote what their intentions were and merge it with your code in a way that doesn't cause conflicts or unintended behavior and be before they check in their code they should make sure that all of the unit tests still pass just in case that the new code or the change that they wrote breaks something else and see before checking in their code they should run the lint tool and fix any code that doesn't conform to the style guidelines set forth by the team now even if a developer does all of this and has the best intentions we are all still human and mistakes will happen code will be improperly merged builds will break tests will fail and bugs will crop up it would be a full-time job for someone to continuously monitor the codebase and make sure it's in tip-top shape after each time a developer checks in code well fortunately we don't need to do this and this is where something called continuous integration or CI for short comes in real handy continuous integration is a system that monitors the master repo and runs various checks and balances to ensure that the master code base is in tip-top shape the CI process is highly configurable and it can automatically do things like build the project to make sure it runs run the test suite to ensure that all of the unit tests pass run a lint tool to check for code that doesn't adhere to coding conventions and it can even do more than that such as send a successful build to a QA environment or deliver it to iTunes for deployment into the App Store it can do all these things automatically by running on a specified schedule or running whenever someone checks in code if the CI process finds a problem the appropriate people can be notified immediately to fix the problem like maybe if the build is broken after the last code check in or a unit test no longer passes or maybe the newly checked in code fails the Lin tests knowing about any issues right away is crucial especially with a large team because so much code is being written per day that it can quickly pile up on an issue and it can take a long time to unravel the issue if it remains buried a continuous integration system lets the team work confidently and stay focused on coding because developers know that the CI process will catch any mistakes as soon as they happen continuous integration often goes hand-in-hand with continuous delivery which is a process that can automatically send builds to different environments such as sending the build to a test environment for the QA team to test out some new features circle CI is one of these platforms that can do all this and more now we're going to do a demo and I'm going to show you and put into practice everything we just talked about we're going to start a new Xcode project and we're going to commit it to a source control management system now git is a popular choice and it's a great one for us to use because there's tight integration for it within the Xcode IDE however we're going to use github so we can actually store our git repository on the cloud then I'm going to show you how to write us unit tests and I'll show you how to run it finally we're going to hook up our github repository to circle CI so that every time we push code from our computer to github circle CI is going to get the latest code from the master repo run our unit tests build the project and also used Swift lint to make sure that everything is okay all right so let's dive in all right so we're gonna start our brand-new Xcode project and I'll show you how to put it on github so our first step is to create our Xcode project so go ahead launch Xcode let's create a brand new Xcode project I'm going to choose a single view app here and for the product name I'm just gonna call it large project because that's what we're talking about right now the important thing is to include unit tests because I want to show you guys how to write a sample one and run it and go ahead click Next you can save it wherever you want I'm gonna put it on my desktop now what's also important is to check source control here it's gonna create a git repository on your Mac don't confuse this with github this is a local git repository it's still source control the only thing is that that repo is stored on your machine now as a single developer this might be fine but you do have to think about the risk of potentially your hard drive failing and then you'll lose your code so it's always a good idea to put that on github and I'll show you how to do that so go ahead and enable this for now click create and here we are we have our sample project the next thing we're going to do is to sign up for a github account if you don't have one already and the great thing is that private repositories are free now it used to be that only public ones who were free so all your code would be public but now even private repos are free as well so you don't have to pay anything so sign up for github go to github com if you haven't gotten an account if you do then you can move on to the next step which is hooking up Xcode with your github account and the way you do that is you go - Xcode preferences and you can see here I have my account hooked up if you don't have this go ahead click this plus icon here and just choose github from the list and it's going to ask you for your account and password so you want to go ahead and do that so that you can integrate X code with your github account and so you can push code and pull code back and forth very very easily so after you do that the next thing we're going to do is to put this large project into our github account and the way you can do that is you can go here this is where you can look at all of your source control Navigator this what it's called and you can actually go under branches if you're not aware you can have different branches or versions of your source code and you can choose which ones to pull from and which ones to send code to initially you're only gonna have master and we've only really talked about master but starting a separate branch might be good if you want to test out a new feature or you want to maybe tinker with something that you're not sure you want to put into the master just yet so at that point it could be helpful to create a separate branch or separate version of your code at that point tinker with that and then depending on if it fails or you want to add it to the master you can always merge it back into the master branch so usually we just have our master branch to start so in order to put this whole project on github you go to this node right here and you right click and say create large project remote and remote means just off of your computer into github you've choose the account so hopefully you've added your github account through your Xcode preferences you're gonna give that repository a name alright so you can see here that this is ultimately the URL where that repo will live you can give it a description you can always edit this after I'm gonna set it to private right and then I'm just going to create it and then you can see here this is pushing its pushing the code to github and then now we can just jump into github and this is my github account here so you can see that when i refresh the page there it is this little lock represents that it's a private repository so you can see here that's the initial commit I've got a bunch of files here this is my actual project this is my tests and you can see that it mirrors what I have here okay so that's really cool because now whenever we write new code we can push it to github and in case our hard drive gets fried our code is safe on github now what I want to do is just run through quickly at a high level unit testing how to run test cases for your project and we're not going to really dive deep into testing theory or writing a lot of meaningful tests because the point of this video is to show you the overall process alright so you'll notice that we have large project tests here and if you click into this file here you'll see that we have this class large project tests there are a couple of methods here set up teardown and here is a single test case sample so you can also run performance tests but in this case we are not going to do that I'm just going to show you how to do simple functional testing to test the functionality and correctness of your code so let's go ahead and erase this performance test and we are just going to focus on this test sample now what we've got here is we've got one test case and then we've got our setup and teardown methods so these two are going to be called before and after every single test case now they're basically there just in case you need to write a whole bunch of setup code just to get to the point where you are able to write some code to run your tests and teardown is going to be called after every single test case in case you need to deallocate memory or do any sort of cleanup or put things back in place essentially so what we're going to do here is write a very very trivial test case because our at this point doesn't really do anything but I still want to show you the process of running failing passing tests so I'm going to just create a simple simple variable here let's say let a equal zero and then you know you wouldn't put that there you would put whatever code you want it to test let's say of creating accounts we mentioned earlier you might test passing some dummy data into that code that creates accounts and then you would then want to assert a certain outcome that you expect so the way we do that is we use xct assert and there are different methods here you can check if the outcome is nil if it's true if it's false if that's equal to something but basically the idea is that you run some code right to test something and you have an expected outcome and you use this to assert that that is actually the outcome that you've got in our case I'm gonna write each reveal statement here we are going to assert that I is equal to zero and then if it's not this error message or this message is going to get displayed is you know so that's going to be the message that gets displayed if that isn't true now how do we run this simple unit test there are several different ways you're gonna see some diamonds in this line number column you can run this individual test case by hovering over it and pressing this so I'm just going to go ahead and do that and you're going to see something appeared down here in the console so you can see that it executed one test with zero failures you can eat then these turn to green checkmarks there is also this button here which you can run the differences that hitting this will run all the test cases in this test suite whereas this one will only run this single test case another way is within the test navigator this tab right here you can see that you have your individual test cases here and then another way is actually to hold your over here and instead of building and running your project you would run your tests by itself so those are a couple of different ways now before we check in our changes into github let me show you what its gonna look like if the test fails so let me do that and just change I equals to one this is definitely gonna fail so if I run this test case you're going to see that it's gonna build the project it's gonna fail the test right here so you can see that that statement is not true so I'm going to change it back to zero and then now we're going to push our changes to github so if you go back to the file navigator I want you to notice one thing remember when I said that there was tight integration with git take a look at this we modified this file by changing some of the code we got rid of one of the methods and you can see this M here beside that file that stands for modified and that basically tells you what's changed since the last time you pushed your code to github or your local git repository so if we wanted to commit this code and push it to github we would then right click go to source control and say commit large project tests thought swift when you do this you can fill in a message here to say what you changed why you changed it what it was for and then make sure if you actually want to push it to github the remote repository and not just your local repository you enable this you choose your branch you know what we talked about earlier and we can say added a revealed test case all right so we can commit that file and push it so technically committing is actually a little different from pushing even though a lot of people use them these terms interchangeably committing is saying that I'm done with these files and these changes are related to whatever message that you put whereas pushing is actually the physical action of putting your code into sending it to the repository so you can actually do a whole bunch of different commits locally before you push your code to the repository I know that might not make that much sense for now if you're kind of neat to source control but think of it like a commit is a particular change that you want to make and pushing is actually sending the code to the repo all right so let's go back to our github repository and let's just hit refresh and you can see here that this was our latest push right a minute go whereas our initial project push was 21 minutes go in if you actually take a look at here you can see there were two commits right so this was the initial one for the whole project and here was our trivial test case Edition and each one has a version number right so this source control repository or management system knows exactly when something has changed if someone else had checked out the code earlier and they try to push their changes source control is going to say hey and we're at a new version now so you better pull down the latest changes and merge them before you push your code over so that our test case doesn't get overwritten so just to do a quick recap we've created a brand new Xcode project we've put it on github so now actually multiple developers can start working on this project and this source control management system is going to work beautifully however we are counting on each single developer to be diligent in running the test cases and also they have to write the test cases right to ensure that the code they add doesn't break the build and that our app still functionally works this cannot always be relied upon despite the best intentions of each developer and so what our next step is going to be is to hook up our github account or this specific repository with circle CI so that we can get a continuous integration process working so each time a developer pushes code to the master repo circle ci is going to detect at and automatically grab the latest code build it to make sure that it's still build successfully run all of our tests to make sure that they all pass and I'll show you also how to include a lint tool and have that run so that the code can be checked to adhere to the coding conventions of the team all right so let's go ahead and do that so visit the URL on the screen right now or click in the description for the link and you're going to get to the relevant page for building and testing Xcode projects on circle CI start building for free click on that and you're going to be able to sign up with your github account and doing this is going to be good because it's going to automatically give Circle CI access to your github repositories now you can control whether circle CI has access to your public and private repositories or only your public ones so on the next screen you're going to see that and then once you're signed up and you're into the dashboard you should see something that looks like this and you might not have any projects at first or you might see something here but go ahead into the add projects tab and you're going to then jump into the Mac OS tab here then you're going to be able to start two week free trial and there's no credit card entry or anything like that so feel free to give it a try click on start my free trial and then you're going to see your project here now I'm going to refresh the page so we can see what I have here so there we go that's the large project that we just added to our github account so go ahead and click on the blue button to setup your project and this should be automatically detected if it's not you can choose Mac OS and Swift right here and there is only really one thing that we need to do to set this up and get this going and that is to setup a configuration file that tells Circle CI what we want to build what we want to test you know what lint tool we want to use how we want to distribute to build - what environments and all that stuff and so I'm gonna show you what that configuration file looks like and a couple of different options for configuring it so what we're going to be doing now is following this documentation right here on testing iOS applications now I'm gonna put all of these links in the description below so you don't have to run around looking for these but let's take a quick look I'm not going to go through it in very much detail because I'm gonna demonstrate it for you so the basic setup involves making sure that circle see I can access the Xcode scheme that you want to use now if you're unfamiliar with what a scheme is let me show you inside Xcode and actually this is kind of bothering me the fact that there are these red X's there so I'm just gonna run the test case and pass it I really much rather see green checkmarks alright so let's talk about schemes this right here is a scheme and if you've never clicked on this before it's probably because you didn't have to when you create a new Xcode project you have a default scheme that is the same name as your project right here and a scheme it basically describes which targets you want to build what tests you want to run what configuration files and stuff like that do you want to use because an Xcode project can actually be comprised of many different projects and targets and the scheme will allow you to specify you know which of those projects and targets you want to use and which tests you want to run and so on and so forth it's basically like a plan so the only thing we need to make sure is that our default scheme right here large project is shared so click this go to manage schemes and just make sure that this is checked on and it should be so you can go ahead and close that and I don't think I don't know if we pushed our latest test here I believe we did actually this is probably something we have to do to is to put the scheme into github because that is one of the one of the instructions here after we make sure that our scheme is shared we have to put it on github so that circle CI can access it because circle CI can only grab what's in the github repository so once you edit that scheme and make sure that it's shared go ahead under source control go to commit it's going to show you a list of files which have been changed which haven't been committed and pushed to github yet and you can see here that there is this data right here so just let's just push that we're going to do that and we're going to commit this file and we're going to push it alright so there is that change right there alright so now going back to the documentation this is what that configuration file looks like now we need to create this file and we need to put it on github so let's take a look at what's involved it looks complicated but it's really not I've actually taken this sample and I've simplified it a little bit so that it's a lot easier for me to explain and to for you to understand so what you need to understand is there's this notion of a job and a job is something that you tell Circle CI to do each job has a series of steps so for example you can give your job a name like job one and then you can specify the steps that circle CI must do for example check out the code and then run some sort of command maybe run another command and you would of course I'm simplifying it here but you would write down two specific commands that you would want Circle C had to run and then maybe like save the output of that command somewhere save the results somewhere you can also specify what sort of you know environment or what sort of version of Xcode you want circle CI to use and then you could have multiple jobs you can have a second job to do something else and that would have its own steps and then you can have a third job so this is all listed under jobs and then you have something called workflows and workflows allow you to take and pick and choose different jobs that you want to run so you can have one workflow and then you can list out which jobs make up that workflow so for example maybe this one is testing the project maybe this one is going to be you know linting the project or the code and this one it might be to you know do something else and then within each workflow that you specify you can specify pick and choose different jobs that you want to run to make up that workflow so for example workflow one that I've specified here is made up of job one and three so when circle CI sees this it's going to run this workflow and then it's going to run job one and three so I hope that kind of makes sense just to sum it up you have a series of steps which make up a job and then you have different jobs that make up a workflow so if we go back to the sample config file that it has here now it kind of makes a little more sense right so let's go through this sample config file and let me explain it to you so here's the list of jobs this job is called build and test here is the environment and version of Xcode that we want Circle CI to use here we're specifying an output directory here are the steps for the build and test the job first that's going to check out the code from github then it's going to run and for this run command you can give it a label or a name it's going to fetch cocoa pod then it's going to run this command right here to install cocoa pods and to read the pod file just in case your Xcode project is using any third-party libraries via cocoa pods then it's going to go ahead and install all of those third-party libraries and then here it's going to run a fast lane skin command and fast lane is another automation tool you know if you haven't done a lot of development you might not have had the need to look into a tool like this but when projects get bigger and the deployment process gets bigger in you know you're running tests you're generating screenshots and you are deploying it to various environments it takes a lot of time to go through all of those steps every time you know there's a code change or a feature completion or something like that and you need to roll something out so fast lane helps you automate a lot of those tedious tasks and fast lane works with circle CI so that's that's really great you can see here some of the features that fast lane can help you with alright so going back to this config file running a fast lane scan in this case is basically going to run your scheme your Xcode scheme we're going to change this to our scheme that we have which is large project and it's going to run all of our unit tests and it's going to use this device or simulator here and then it's going to save those results somewhere and that's the job right there and here we specify workflows so this is the build and test workflow and the jobs that make up this workflow is the build and test job so I hope that makes sense what we're going to do now is we're going to take this sample config file we're going to modify it to our own needs and then we are going to put it into github so then we're going to be able to see circle CI in action so how do we go about creating this config file well the easiest way and actually from the set of instructions right here in the getting started the easiest way to create this config the siamo file essentially is to go to your github repository click on create new file and then we're going to specify the file here so it's got to live in this hidden folder called circle CI and you know it's hidden because there's a dot right in front of it if you don't have hidden files shown on your local system then you're not going to be able to see it but I'll I'll talk about that in a second so you paste that you're all there and it automatically detects that you want to put this file config yamo into this hidden folder circle ci and in here you put the contents of your config file so we're going to go ahead and we are going to just copy this and we are going to paste it in here but we're gonna have to make some changes so for example I want to use ten point two point one and if you go back into this document right here it tells you supported Xcode version so these are all of the different versions of Xcode that you can decide to use all right and I'm choosing this version simply because that's the version I'm currently using I don't need any cocoa pods for our sample project right now it's pretty simple we don't have any third-party libraries with cocoa pod so I'm gonna get rid of that and then it's gonna run Fastlane scan iPhone 8 is fine and our scheme is not web tests it's actually if I go manage schemes our scheme is called large project so that's what we're gonna have to put here large project and the rest should be fine so we're gonna go ahead and commit this new file into our github repository so let's call this creating the config file for circle CI right and when I commit directly to the master branch let's go ahead and do that all right so now let's go back to our root and you can see there is a hidden circle CI folder now if I navigate to my large project folder locally on my desktop I don't see that file there I don't see that configuration file I just added to github so what I've got to do is just go into my Xcode project and under source control let's do a pull so this is going to get the latest changes from our remote repository let's go ahead and do a pull and I'm gonna go ahead and pull from the master branch and if we check our directory now now we have that configuration file and like I said if you don't have hidden files shown on your computer then you're not gonna see these hidden folders and there is a way for you to enable and show these hidden folders just go ahead and google show hidden files on Mac OS or whatever version you're using and you're gonna see some simple instructions to enable this okay so now what we can do is we can go back to circle CI and we can start testing our project so this part is really exciting so we've done all of this we created the circle CI folder with the config Yama file we've populated it we've updated it push this change the github we've done that lo so let's hit this button to start building our project it's gonna grab the latest code from github and you can see here this is our workflow it's running it I'm just gonna have to wait [Music] all right so it's succeeded let's take a look at what's happened if you click into it you can see everything that it's done so go ahead here we go you can see that it's setting up the environment it's checking up the code and you can always go into here to see the exact commands it's running and the things that it's doing build and run tests so you can see here it's running Fastlane scan and it's running this scheme here large project for our Xcode project right there they're a whole bunch of different things that you can look at now why don't we do a cool test here why don't we go back to jobs and you can see that succeeded but let's go back to our Xcode project now and let's break our test so let's say that let y equals 1 and then I'm gonna run this and obviously it's gonna fail right but we are going to push this into github and see what happens so let's save the file let's go here you can see that it's modified let's go ahead and commit this so let's say I was a developer and I was committing some code and you know break the unit test let's commit and push all right you're going to see that circle CI is going to pick up the change and then it's going to automatically run try to build the project and then run the unit tests again and so that happens automatically you don't even have to do anything [Music] all right so circle CI has finished running our job took about a minute and a half and as expected its failed so let's click into it and see what's happened so you can see that checking out the code was successful but building and running tests failed and you can see if we just take a look at the output here that C is supposed to be zero this test failed test example' failed and so immediately what's going to happen is I'm gonna get an email workflow failed right so this latest code change whoever pushed this into the master repo has essentially broken some tests that failed so now someone can go in and address it right away whether that is the person who made the commit or someone else but the key thing is that we found out about it right now rather than you know several different commits later and the issue is buried and hard to figure out so now let me go ahead and change that back so that it's working let me say fixed unit test all right push that and so circle CI is going to detect that and it's going to do its thing now while that's happening let's take a look at linting so there is a free and awesome lint tool called swift lint and it is a tool to enforce Swift style and conventions loosely based on github swift style guide so it's kind of based on this one but all of these lint tools are very configurable and so you can you can change the rules to what you need and what you like the cool thing is that you don't really need to do much to lint your code through circle CI so let's take a look at how we can modify our config file to include linting we are going to use this right here so this is a lint job which we can copy this configuration for and we can add this to our configuration file so why don't we go ahead and copy these steps we are going to go into our config dot yeah mol file and just click Edit and we're going to change this a little bit so we've got our build and test job here I'm gonna add a new job it's basically the code that I took from here and this is going to be the Swift lint job and this is how it looks like it's going to check out the code and then run Swift lint and then store the results but in order to include this job into our workflow we actually have to modify our workflow here build test let's say lint build and test right so then we add with the wind right there and now let's let's check out our build here it's still running ok it should almost be done oh there it is succeeded so remember I fixed the test case right here it shows you the latest commit so that's kind of cool and then now I'm going to commit this so updated config circle CI config file to include linting and just commit that and take a look at what happens here alright so it's running now here's the workflow lint build and test and here is the job this one is testing the build and test job and this one is running the Swift lint job so it's gonna run and let's give it a little bit of time and see what happens alright so our new workflow has finished and the linting took about 22 seconds and building and testing took about a minute half same as before now this has succeeded as expected but our linting has failed so let's take a look at that we're gonna click into it and we are going to take a look at Swift lint reporting on all of these violations you can see here done linting found 15 violations three serious in three files now the only files we have essentially are in terms of Swift code right app delegate view controller and large project tests swift so let's take a look at what Swift Flint has to say about that here failure message files should have a single trailing newline and it tells you that this is in viewcontroller.swift it also tells you that inside viewcontroller.swift limit vertical whitespace to a single empty line so I'm not gonna go through all of these and fix all these for you now but I do want to fix a couple ones and show you what that looks like so files should have a single trailing newline if you take a look at here it's basically saying that I have two new lines after it and I should have one so you know it can get pretty detailed again in app delegate Swift I have two trailing new lines at the end and it should only be one and oddly enough large project I thought a large project tests the Swift only has one so now everything is consistent right other rules include that line should be 120 characters or less you know this is saying that some of this code is going way too much into the right and so if people were to read it they'd have to scroll left and right too much right so there are some rules that say that your code should be written in a way or space in a way so that it's not too wide so all of these rules are really configurable but at the end of the day it's gonna help you maintain a very tidy and consistent code base so we've just made two changes right so let's commit these two changes fixing let's push the remote fixing new trailing newline violations how about line lint violations commit these two files and push now here's a very interesting I want interesting thing I want to tell you about so we've just pushed we fix two violations right so we should see this go from 15 to 13 the next time we do this but if I go into jobs you can see that Circle CI hasn't triggered so why is that well if we go back to github and we refresh the page and we look at our number of commits we don't have we don't have the latest commit that we did my message was fixed trailing newline lint violations right I committed that but where did that go right the problem is that we changed our master repo from this web-based interface and so it's out of sync with our local copy right here so that's why I wasn't I wasn't able to push my those code changes into github instead what I have to do is first pull any changes or I pull them basically they were changes to the configurable file so now that I have all of the latest changes I need to merge any conflicts but there weren't any so now actually I can go in and push the code I can push my last commit so now it will actually succeed so if i refresh the page now you can see here that this contains my latest change fixed trailing fixed trailing newline lint violations and now circles see I will pick up that new commit and it's going to run the lint test again and it's going to build my project and run the unit tests as well all right so circle CI is finished linting our code and also building and testing our project so building and testing our project has succeed as expected but swiftlet has still failed and that's because we didn't fix all of the errors or violations right if we go down here now it's only found 13 instead of 15 because we fixed two of them right so we're still in violation but I just wanted to show you that as an example so here we also get emails to notify us that swiftlet has failed someone has checked in some code that has violations and so you should go and address that right away so as you can see all of these tools help teams collaborate and work together efficiently and once you set it up it just works for you and you can focus on writing your code now there are two very important things I want to mention and number one is that these tools and processes are very common in the industry so if you have experience with them or you build the skills in using them it's going to give you a huge leg up in getting hired as an iOS developer if that's your goal and number two I've spoken about these tools in the context of large teams working together but I hope you can see how these things can even help a single indie developer building his or her app by offloading a lot of the tedious tasks and also automating the testing side of things it's gonna allow that developer to save time the precious 24 hours that he or she has and just focus on writing code now in the future I want to dive deeper into some of the topics that we had to gloss over such as configuring Swift Lin unit testing using fast lane if that's something that you want to see please drop me a comment below and let me know that's gonna give me a huge vote of confidence to move forward on these topics and finally I want to thank Circle CI so much for creating such a great product for developers to create awesome apps and also for sponsoring me and allowing me to create high-quality and free tutorials for you guys so there's start making continuous integration and delivery a part of your development process click the link below and sign up for a free account

Channel: CodeWithChris

Views: 13,221

Keywords: circleci, continuous integration, continuous delivery, continuous integration tools, continuous integration with github, circleci part 1 continuous integration with github, circleci tutorial, circleci github, continuous integration tutorial, continuous integration and continuous delivery, github, xcode, source control, circleci github integration, app developer

Id: VGVw8fnc5YY

Length: 51min 14sec (3074 seconds)

Published: Wed Aug 28 2019