Continuous Integration for Open Source Projects with Travis CI
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 96 | |
| Autor | ||
| Lizenz | CC-Namensnennung - keine kommerzielle Nutzung - Weitergabe unter gleichen Bedingungen 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben | |
| Identifikatoren | 10.5446/51708 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
00:00
Open SourceOffene MengeKontinuierliche IntegrationKontinuierliche IntegrationOpen SourceMultiplikationsoperatorClientIntegralQuick-SortFormale SpracheSoftwareentwicklerFlash-SpeicherDezimalzahlGruppenoperationComputerspielBitPunktSkriptspracheData MiningÄhnlichkeitsgeometrieDatensatzUMLComputeranimation
00:44
Cookie <Internet>COMDokumentenserverKontinuierliche IntegrationCodeSoftwareentwicklerBitMultiplikationsoperatorData MiningPunktDienst <Informatik>MathematikIntegralDateiformatRechter WinkelVersionsverwaltungPhysikalischer EffektSoftwareentwicklerE-MailMinkowski-MetrikElektronische PublikationSoftwaretestProzess <Informatik>ClientKonfigurationsraumGanze FunktionProgrammbibliothekUniformer RaumSoftwareMathematische LogikDokumentenserverAnalytische FortsetzungFormale SpracheCodeGeradeProjektive EbeneFigurierte ZahlKontrollstrukturDatenverwaltungInformationOpen SourceAuthentifikationMereologieGemeinsamer SpeicherKontinuierliche IntegrationBildschirmsymbolAdditionStabilitätstheorie <Logik>Physikalisches SystemGrenzschichtablösungZweiBenutzerfreundlichkeitAggregatzustandDistributionenraumQuick-SortAbgeschlossene MengeProfil <Aerodynamik>Vorzeichen <Mathematik>Hinterlegungsverfahren <Kryptologie>Computeranimation
07:35
DokumentenserverKontinuierliche IntegrationCodeSoftwareentwicklerOpen SourceMultiplikationFormale SpracheAppletKontinuierliche IntegrationCodeFormale SpracheFigurierte ZahlVerzweigendes ProgrammProzess <Informatik>VersionsverwaltungGewicht <Ausgleichsrechnung>Schreiben <Datenverarbeitung>Physikalisches SystemÄhnlichkeitsgeometrieOpen SourceSpeicherabzugValiditätMultiplikationsoperatorDifferenteSoftwaretestVerkehrsinformationGeradeDienst <Informatik>Konfiguration <Informatik>UnternehmensarchitekturElektronische PublikationOffene MengeBitProjektive EbeneTermBasis <Mathematik>MereologieGebäude <Mathematik>ServerKonfigurationsraumSoftwareCodecKomponententestKeller <Informatik>IntegralSoftwareentwicklerArithmetische FolgeHumanoider RoboterBildschirmfensterProgrammfehlerPolstelleBrennen <Datenverarbeitung>QuaderProgrammierumgebungGüte der AnpassungMultiplikationAnalytische FortsetzungNP-hartes ProblemSchnittmengeRechter WinkelVirtuelle RealitätGanze FunktionWeb logRechnernetzBimodulComputeranimation
14:02
BimodulFunktionalComputervirusSchnittmengeSoftwaretestPunktFormale SpracheProjektive EbeneGebäude <Mathematik>CASE <Informatik>Computeranimation
14:38
SoftwaretestTypentheorieFormale SpracheElektronische PublikationKonfigurationsraumBeobachtungsstudieGebäude <Mathematik>VersionsverwaltungProjektive EbeneSkriptspracheAuszeichnungsspracheMultiplikationMailing-ListeMatrizenrechnungKomponententestDifferenteProzess <Informatik>TouchscreenWort <Informatik>Computeranimation
16:28
SkriptspracheGebäude <Mathematik>Installation <Informatik>ComputerspielDrucksondierungWurm <Informatik>InstantiierungPhysikalisches SystemProjektive EbeneInstallation <Informatik>RechenwerkSoftwareGebäude <Mathematik>ProgrammierumgebungDienst <Informatik>Service providerFormale SpracheSkriptspracheSchnittmengeTouchscreenDefaultOpen SourceCodeBildgebendes VerfahrenVirtualisierungQuick-SortVerzweigendes ProgrammElektronische PublikationSoftwareentwicklerSystem FMathematikDatenverwaltungInformationKonfigurationsraumDreiecksfreier GraphEreignishorizontServerComputerspielLoginProzess <Informatik>eCosRechter WinkelMomentenproblemUnrundheitOffice-PaketKomponententestCASE <Informatik>Weg <Topologie>Virtuelle RealitätDatenbankZweiGesetz <Physik>LastVersionsverwaltungMultiplikationsoperatorDatenflussBitTurm <Mathematik>Zellularer AutomatVollständigkeitComputeranimation
21:42
Zellularer AutomatProjektive EbeneOpen SourceSkriptspracheGeradeKomponententestBefehl <Informatik>FehlermeldungMathematikMinkowski-MetrikProgramm/QuellcodeComputeranimation
22:20
PrimzahlzwillingeBenutzerbeteiligungDokumentenserverHilfesystemVerschlingungGüte der AnpassungVorzeichen <Mathematik>Message-PassingWeb SiteKontrollstrukturHook <Programmierung>BitWechselsprungLoginGebäude <Mathematik>Physikalisches SystemMultiplikationsoperatorVersionsverwaltungStabilitätstheorie <Logik>ProgrammierumgebungFigurierte ZahlProgramm/QuellcodeComputeranimation
23:27
TabelleKlon <Mathematik>VersionsverwaltungInstallation <Informatik>GradientFehlermeldungCodeFunktion <Mathematik>ComputervirusBildschirmfensterGebäude <Mathematik>InformationPhysikalisches SystemPolygonnetzTermDynamisches RAMSpeicherabzugInverser LimesFontBildschirmsymbolUmwandlungsenthalpieVersionsverwaltungHilfesystemProzess <Informatik>Verzweigendes ProgrammDatenbankGebäude <Mathematik>MultiplikationsoperatorGarbentheorieEreignishorizontPunktFormale SpracheElektronischer ProgrammführerInstallation <Informatik>Elektronische PublikationOpen SourceKonfiguration <Informatik>ServerInformationDienst <Informatik>Physikalisches SystemDefaultKonfigurationsraumSkriptspracheMatrizenrechnungZahlenbereichProgrammierumgebungProjektive EbeneHalbleiterspeicherStabilitätstheorie <Logik>p-BlockFehlermeldungProgrammierspracheQuick-SortFahne <Mathematik>VariableToken-RingAuthentifikationRechter WinkelMinkowski-MetrikFortsetzung <Mathematik>CAN-BusInformationsspeicherungStrömungsrichtungWeb SiteFlächeninhaltSoftwareentwicklerComputeranimation
28:19
Demo <Programm>Konfiguration <Informatik>E-MailMereologieDatenbankBitTypentheorieElektronische PublikationDienst <Informatik>DifferenteFortsetzung <Mathematik>SystemaufrufProgramm/Quellcode
29:15
DatenbankMathematikDreiecksfreier GraphExogene VariableDatenbankGebäude <Mathematik>BitDemo <Programm>SkriptspracheSchlüsselverwaltungPhysikalisches SystemClientInformationRechter WinkelSoftwaretestProzess <Informatik>ComputeranimationProgramm/Quellcode
30:06
Lemma <Logik>ClientMathematikRechenwerkDynamisches RAMSchlüsselverwaltungElektronische PublikationDienst <Informatik>ClientInformationsspeicherungPhysikalisches SystemDatenverwaltungLie-GruppeValiditätWeg <Topologie>FehlermeldungSystemaufrufInformationComputeranimationProgramm/Quellcode
31:10
Pay-TVVersionsverwaltungProjektive EbeneCASE <Informatik>VerkehrsinformationVerzweigendes ProgrammMultiplikationsoperatorEinsProdukt <Mathematik>CAN-BusDokumentenserverVierzigIntegralDienst <Informatik>Figurierte ZahlKonfiguration <Informatik>ServerTUNIS <Programm>Service providerE-MailAdressraumCodeSchlüsselverwaltungKonfigurationsraumMailing-ListeComputersicherheitRepository <Informatik>Programm/Quellcode
32:51
E-MailVersionsverwaltungPatch <Software>Demo <Programm>Projektive EbeneVersionsverwaltungPatch <Software>HilfesystemInformationLeistung <Physik>Service providerProzess <Informatik>LochkarteGüte der AnpassungE-MailAdressraumPunktZahlenbereichSkriptspracheStrömungsrichtungKonfigurationsraumGebäude <Mathematik>Mailing-ListeGeradep-BlockProgramm/Quellcode
34:08
Web logSystem-on-ChipGebäude <Mathematik>ZahlenbereichInformationGüte der AnpassungElektronischer ProgrammführerDienst <Informatik>Programm/QuellcodeComputeranimation
35:03
Inklusion <Mathematik>VersionsverwaltungGarbentheorieElektronische PublikationE-MailProzess <Informatik>MereologieAdressraumVerzweigendes ProgrammChiffrierungSchlüsselverwaltungBitMailing-ListeGeradeHilfesystemProgramm/Quellcode
35:45
E-MailInstallation <Informatik>VersionsverwaltungPatch <Software>AppletGarbentheorieDateiformatLesen <Datenverarbeitung>BitProzess <Informatik>Projektive EbeneMathematikMereologieMailing-ListeProgramm/Quellcode
36:34
HilfesystemPhysikalisches SystemGebäude <Mathematik>InformationKlon <Mathematik>KnotenmengeVersionsverwaltungRechenwerkNormierter RaumRFIDPatch <Software>PASS <Programm>Lokales MinimumVerzeichnisdienstAuthentifikationTablet PCIndexberechnungVerzweigendes ProgrammSchreib-Lese-KopfDateiformatBildschirmsymbolElektronische PublikationFächer <Mathematik>Gebäude <Mathematik>Projektive EbeneE-MailKonfigurationsraumProzess <Informatik>ZweiDemoszene <Programmierung>Expandierender GraphVersionsverwaltungAdressraumZahlenbereichSystem FSoftwaretestBitElektronische PublikationRechenwerkMultiplikationsoperatorInformationRepository <Informatik>Dienst <Informatik>AdditionDokumentenserverFigurierte ZahlKartesische KoordinatenFehlermeldungDatenbankMathematikVerzeichnisdienstProgrammierumgebungAchtRechter WinkelVektorpotenzialResultanteAuthentifikationProgramm/Quellcode
39:40
E-MailChatten <Kommunikation>MultiplikationsoperatorProjektive EbeneDefaultTUNIS <Programm>Quick-SortSystemverwaltungKonfiguration <Informatik>IdentifizierbarkeitE-MailIntegralAdressraumMereologieProgrammierumgebungGarbentheorieVerband <Mathematik>Computeranimation
41:14
E-MailGarbentheorieAdressraumMailing-ListeKonfigurationsraumKonfiguration <Informatik>IndexberechnungSchnittmengeProgramm/QuellcodeComputeranimation
41:52
GammafunktionKartesische KoordinatenPolygonzugCOMSchwappende FlüssigkeitApp <Programm>Prozess <Informatik>HoaxElektronische PublikationDemoszene <Programmierung>ChiffrierungLie-GruppeGeradeClientDesign by ContractInstallation <Informatik>Computeranimation
42:54
OISCGebäude <Mathematik>Physikalisches SystemOpen SourceMultiplikationsoperatorEreignishorizontBildschirmsymbolGebäude <Mathematik>Quick-SortSoftwareentwicklerCodeProjektive EbeneMathematikIntegralRepository <Informatik>Rechter WinkelAnwendungsdienstanbieterInformationBitVorzeichen <Mathematik>Open SourceVerzweigendes ProgrammProzess <Informatik>PunktExogene VariableSpeicherabzugURLPhysikalisches SystemGewicht <Ausgleichsrechnung>Bildgebendes VerfahrenGeradeASCIIE-MailBildschirmfensterDigital Rights ManagementWort <Informatik>DatensatzSystemplattformDemoszene <Programmierung>Konfiguration <Informatik>Lesen <Datenverarbeitung>QuaderGreen-FunktionRückkopplungTaylor-ReiheProgramm/QuellcodeComputeranimation
Transkript: Englisch(automatisch erzeugt)
00:05
All right, so this is continuous integration for open source projects with Travis CI. My name's Kyle Tyack. I'm an API evangelist with Akamai. I spend my days working with our clients to streamline their workflows and to get up speed with our open APIs. So I spend a lot of time with HTTP requests
00:21
and debugging and fun stuff like that. When I'm not working on the API stuff, I like to dabble in Node.js. I do a lot of full stack developments. In a former life, I spent 10 or 12 years freelancing and working heavily in Flash development, ActionScript. So JavaScript's sort of a second language for me. It makes sense. It's very similar to ActionScript.
00:40
When I'm not coding or working with clients and traveling and speaking at conferences, I spend a lot of my time brewing beer. I've got a bit of a problem with it. It's become a bit of an obsession of mine. So you can pretty much always find me talking to somebody about beer. If beer is an interest of yours, pick my brain after the session. It's gotten kind of the point where I'll talk to just about anybody about beer.
01:00
For the record, turkeys don't drink beer despite my best efforts. I thought he might taste better if he had a few of these, but he didn't bite, so. Gonna tell you guys a little story today. And this is a story about obsession, about love, about heartache, pain and passion, conflict, about late nights and early mornings, about a deep and driving desire
01:21
to share a part of oneself. Of course, I'm talking about the management of open source projects. So my story started a little bit strangely. I had just joined Akamai. I wasn't too familiar with some of the projects we were working on, but being the node guy on the team, I was tasked with creating a signing library for our authentication systems in node.
01:40
As it turned out, one of our community participants, the fellow developer, had created a node library for a client he was working for and had open sourced it on GitHub. I reached out to him and said, hey, you know, you've done something great. We'd love to use this internally on our projects. You know, how do you feel about sharing it with us and letting us host it on Akamai? And he said, sure. So that was great, right? I didn't have to rewrite the entire library,
02:00
just needed a little bit of cleaning up. I forked the project, I did some cleanups, and this was kind of my first time working with an open source project. I didn't really know exactly what I was doing. So the first thing I did was clean up all this code. I wanted to make everything nice and uniform, have the same tab spacings, have semicolons in the same places, second line returns for the closing brackets, all that stuff.
02:21
So I did that, I committed it back, I bumped the version up to 2.0, not realizing that that would be a breaking version. And I pushed everything back up to GitHub. And about 30 minutes later, I got an email from the developer saying, what did you do, I can't commit anything, I can't merge, there's conflicts everywhere, what's the problem? So we stopped and talked about it for a little while and figured out that by me performing
02:42
that stylistic update and changing all the formatting on all the files, I had made so many commit changes that he could no longer commit and merge into that code base. So we started talking about ways to handle this going forward and how we could kind of solve this problem of enforcing stylistic changes and uniformity
03:00
across the entire code base. This is something I wasn't familiar with, but it's a process called linting. Basically, that's how you enforce stylistic changes. So if you want to have four spaces mean a tab or if you want to enforce semicolons being at the end of every line, whatever it is you might require for style guidelines in your project, you can enforce that with a process called linting. And there's tools out there for every language.
03:21
For JavaScript and Node, there's a thing called JSCS, which I'll show you guys a little bit later, that actually enforces that stuff. So he recommended I did this and added it to the project. But the thing is, is I didn't know how to enforce things that people were committing on GitHub and ensuring that those changes happen, right? So if somebody else in the audience here wrote a change and committed it up through a pull request, how do I ensure that you're following
03:41
the guidelines that we set forth? And that's what turned me on to this thing called Travis. He recommended I check it out. It's a management for continuous integration service. And basically what it does is allow you to run a build every time somebody commits code, whether that be through a pull request or through a normal commit. However the code is getting into the repository, you can actually run a build and testing and linting
04:01
and everything else across the project. So I implemented it and on doing that, I was able to enforce these stylistic guidelines. So every time somebody committed code, we were able to then check it and say, are they following the guidelines that we've set forth? Had we had this in place the first time when I got my hands on it, it would have been telling me right away as a developer, hey, you've broken this thing.
04:20
It's not gonna work for everybody. You're not following the guidelines. You need to make some changes before you're allowed to commit this. And so that's kind of what turned me on to Travis and the continuous integration idea in general. Another story that might be a bit more familiar, how many people here have created an open source project themselves? Couple of you, okay. So the new GitHub project, right, this is the start of everything.
04:40
You create a piece of software, something you wanna share with the world. It's your baby, you're excited about it. You post it up on GitHub. And after a while, hopefully, people issue some pull requests. This is great, right? People like what you're doing enough that they're willing to write some code against it. It's fantastic, everything's going good. And then you have to merge. It's not a big deal, usually, right? It says you can merge, there's no conflicts. You merge things in, you move along.
05:02
But eventually, you get this, the faded merge conflict. Not the end of the world again, but kind of a pain. You have to pull everything down. You have to check through another developer's code. You have to figure out where the conflicts lie or reformat, fix things up, and then merge everything back up. And this takes a lot of time, and that's something that we all have very little of.
05:21
What happens a lot of times in open source projects is something like this. You end up with this pile of stale pull requests. I see this all the time in projects that I follow. There's 20, 30 pull requests just sitting there, some of them six, eight months old. And to me, the reason behind this is that people just don't have time to handle all the merging of conflicts and everything. So the idea that I'm kind of putting forth here
05:40
is that by using tools like continuous integration and Travis CI, you can sort of ease the process of working with open source projects and merging in all this code. And by doing things like linting and testing your builds as code gets committed, you're actually saving yourself a lot of time, which hopefully prevents things like this from happening. So let's take a look at how this all works.
06:01
Let's first look at continuous integration. So the definition as put forth by ThoughtWorks, a company I highly recommend you follow if you're interested in CI. A guy named Martin Fowler is kind of the guru on this stuff who I studied quite a bit when I was preparing for this talk. Their definition is a development practice that requires developers to integrate code into a shared repository several times a day.
06:22
Each check-in is then verified by an automated build allowing teams to detect problems early. There's a lot of information there that's explaining what's going on, but let's break it down a little bit. A shared repository, it's basically for us, for all intents and purposes, a GitHub repository. Now this could be any sort of version control system. For Travis specifically that we're talking about here,
06:41
it only works with GitHub, so we'll be focusing on that strictly. But the idea of sharing the code obviously needs to be in place, otherwise there's really not much point to this whole talk, right? So you've got your repository up. One thing you want to make sure of with continuous integration too is that everything that's needed to build that project exists in the repository. I don't know how many times I've seen a project where I'd go to a client and take something over
07:01
or go to an open source project, and I'd check out the code and I'd try to do a build and it doesn't work because there's six libraries missing or some configuration file or something else that's not included in that library. So one of the things to remember when you're working with continuous integration is that any developer should be able to check out that project and build it immediately, have everything they need right in one place.
07:22
Several times a day. Now this is kind of an odd concept for a lot of developers. Has anybody here heard of the concept of a release party? Maybe this is a state space thing. It's this really sick and kind of twisted idea that you'd have this little party to release a new code distribution, right? So in standard profiles, you'd work on code,
07:41
say two weeks, three weeks, maybe a month, two months sometimes, and you'd work on these builds, doing commits all along the way, and you'd get this massive merge at the end of the day, right? So two, three weeks into the process, you have this release party, you take all these merges and commits that have been processed over the last few weeks, and you try to merge everything back into the master branch. My first startup job out of college,
08:01
we did this on a regular basis, and I remember one in particular release party that we had that lasted for three days. So you've got this whole team of engineers trying to merge all this code in over the process of three days, and what you end up doing almost always at the end of it is just rolling everything back and then spending another three weeks fixing all the problems. So this idea of committing several times a day is kind of different than your standard approach
08:22
of these long processes of merging in. The idea though is that it breaks your code down into smaller snippets, right? So if you're having to commit at least once a day or more times a day than once, you have to break things down into much smaller pieces, because you obviously can't write 12,000 lines of code if you're only committing in one day. So this has a couple of benefits,
08:41
one of which is that it makes your code easier to debug. If you're committing the day that you made the code and wrote the actual code that you're committing, you're gonna have an easier time finding any bugs that might arise because you just wrote the code. You're not coming back to it six months later or three months later and trying to figure out what you were thinking back at that time. So committing on a regular basis has the added benefit of making it easier to debug.
09:02
It also makes it have a sense of progress. So I don't know how many times I've worked on a project where I'd be working on code for say two, three weeks and I'd just be slogging along, and at the end of it I get to commit. I feel like I finally achieved something. By committing on a daily basis, it gives a sense of progress to the project and it can actually make it seem a lot more fun.
09:21
So being verified, that's the build process part. This is the added value of making sure that anything that's actually making it into the branch is a merge, is been verified by your build process. So whether you run unit tests or you run a linter or you do a version bump or any checks you might need to do during that build process, you're verifying that any code that's actually making it
09:41
into the branch is valid, right? In terms of whatever your build requires. So that is the added benefit of being able to constantly have a branch, whether it's master or whatever branch you use that can be released to production. So automated build, obviously you have to have a way to automate and there's a ton of systems available out there for us. It's gonna be Travis CI that we're talking about today,
10:01
but a lot of people use Jenkins or TeamCity for similar processes. I'll talk a little bit about why I like Travis for open source projects specifically here in a little bit. And detecting problems early. Again, that's the benefit of being able to debug right when you write the code. It's a lot easier to detect something and figure it out than it is going back a few weeks later.
10:20
So the basic process of continuous integration looks something like this. You write your code, you make a commit, it goes into the source control, which triggers a build, right? For us, it's initiating the continuous integration process on Travis. Travis is gonna spin up a virtual environment, actually run your build process. Any tests and anything else you've set up in that build is gonna be run. It's gonna then issue a report back
10:40
and for us, it's gonna go back to GitHub and say, hey, this is what's happening with this build. If it's failed, it's gonna let you know. If it's succeeded, it's gonna let you know. And what that does in terms of open source projects specifically is to give you the ability to see on the fly whether or not a project is able to be merged in, saving you the pain of having to dig through the code and validate everything by hand, spending a bunch of time. So it really speeds up the process and it makes you much more confident
11:01
in the things that are going into your code base. So Travis CI is a hosted continuous integration service that's free for open source projects. They do have an option available for Enterprise now, but it's a paid version. So their big push and where they made their name was really in the open source world. And that's why if you start looking for Travis and projects, you'll see a little Travis.yaml file.
11:22
You'll see that in a lot of the open source projects that you might use today. After I started using Travis, I noticed it in pretty much every project that I use on a regular basis. So to look at this a little closer, it's a hosted service. Now this is the big value add for me. You know, it's also free, which we'll talk about again in a second, but the hosted part is the biggest piece for me. So with something like Jenkins or TeamCity,
11:42
you have to spend a ton of time actually spinning up a server and configuring it and maintaining it. With Travis, they host the entire service for you. So instead of spending your time actually hosting a server, configuring all the software that's on it, upgrading the packages, upgrading the modules, upgrading anything that you run on that server, they take care of all that stuff for you. So all you have to worry about is writing your code.
12:01
And again, for open source projects, time is of the essence. So being able to save time not having to host the server is a big win right away. And it's also free, as I mentioned. So for open source projects, it doesn't cost a dime. You can literally set it up in about 10 minutes and be up and running. Some other benefits of Travis, it's open source. So if you want to contribute back to the project, if you find a bug or if you find an issue
12:22
that requires some new development that you want to contribute to, you can actually issue pull requests back to the project. It's also multi-language. It supports, I think, 29 languages at last check. It's got support for pull requests, which is really interesting and helpful for open source projects because you can actually trigger builds based on pull requests. So most continuous integration stacks only work on commit,
12:42
when you're actually committing code into a branch. But being able to trigger via pull request lets you monitor and identify which merges are able to, or which commits are able to go in very quickly. It's also got simplified deployment processes which we'll take a look at. They've actually worked with companies like Heroku, Amazon S3, and NPM, PyPy, language dependent stuff.
13:01
But they've worked with them to do integrations that simplify the deployment process. So after your build actually happens, it's been greenlit, you can actually immediately deploy out to say Amazon S3 or Heroku and get your project updated. And it's really easy to use, as we'll see here in a minute. Again, on the language support, just a couple of the languages that I've worked with in Travis,
13:20
Python, Node.js, PHP, Go, Android. They don't offer .NET support yet. I know this is a big .NET conference, so I wanted to mention that. In talking with a good friend today, he did mention that there is support for the core system that's coming up for .NET, that that runs on a Linux environment, and given that Travis runs on Linux boxes,
13:41
you should be able to set that up to run as well. I also do know that they are working on adding Windows support and .NET support as an out of the box solution. But to date, there's 29 languages that work, so just about anything you're writing and you should be able to support with Travis. So adding Travis to your project. I created a simple little Node.js project here,
14:01
and again, I figured Node was pretty easy for everybody to understand, and it's also something I work with on a regular basis, but the idea to take away here is that this works for any language the same way. So whether you're working in PHP or Python or Node, it's gonna be the same set of steps to get us all configured. So just to give you a quick idea of what the project looks like, we've got a simple hello.js app
14:21
that does nothing more than have a function called say hello, and it says hello. We also have a single test, because we weren't testing anything, there isn't really much point to having a whole build. And this just tests that we're actually saying hello to the correct name, so in this case, we're gonna say hello to Dave, and it's gonna check that we said hello, Dave. Very simple stuff. So if I go and run our tests, I'm using a thing called mocha to run the test.
14:41
If I type mocha, you can see that all our tests are passing. So far, so good. Now to add Travis to this, we're just gonna add a single file called Travis.yaml. Is everybody familiar with yaml?
15:01
Stands for yaml ain't another markup language, which I still haven't really gotten the joke, because it kind of is a markup language. It's just a way of identifying a config, similar to an RC file or anything else, but the basic idea is that you have keywords, and then you have colons for values. If you're doing a list, you can add item two,
15:20
item three, like that, to add a list of items. So if you're gonna support multiple languages, which Travis does offer, you could add a list like node.js and php, and it would actually build out of matrices where it would run builds across all of those languages. But the very basic bare bones Travis file that does nothing else than run the language
15:40
and the build that it's gonna use and run the build with some simple testing looks like this. We've got a language identified by node.js, and this is actually a keyword that they have in their documentation. And then the versions get specified down here. So again, if I wanted to run multiple versions of node.js to test across different versions, I could do like 4.7,
16:00
and stable is just the latest version of that build. So it's gonna pull down the latest version of whatever stable build is for node.js. If I ran 4.7, it would do a separate build process against the 4.7 environment, and it would let me know how each of them succeeded or failed. So this is really useful if you're, you know, having to test multiple versions for your project. And then finally, it's just gonna run the script tag, and the script is basically our build.
16:21
So everything you put under the script tag is what's gonna run when it builds your project. For us, it's just running that same mocha tag that we ran there. And that's gonna run our unit tests. So if we kinda look back here, full screen this again. You'll see here, I don't know if that's, is that showing up okay for you guys? Big enough?
16:45
You'll see here in this image that what happens when you get a successful build is it actually pushes back to GitHub. So this is all working through the GitHub webhooks. So when you first issue a commit to GitHub, it's gonna tell Travis, hey, I've got a new build coming in, you need to run the build process. Travis is gonna spin up a virtual environment, it's gonna install all the software that you've told it.
17:01
So in this case, it's gonna be node.js, the latest release, and then it's gonna run that mocha process, which is gonna run our unit tests for us. And then it's gonna send back the information to GitHub and say, hey, I either failed or I succeeded. In this case, it's gonna actually say it succeeded, and you're gonna be able to visually identify in GitHub that you have a successful branch that can be merged in, right? So again, saving time, you just look at this
17:22
and it says, all the checks have passed, the branch has no conflicts, it's ready to merge, you push a button, you're good to go. You're not having to check out the code and do all sorts of checks on it. And the same thing if you fail. It's gonna say the checks have failed and this is why. So you can actually see as a developer, this is what went wrong with my code, this is what happened during the build, I can go back and fix it. And as a person managing the project,
17:41
you can then leave comments for the developer to say, hey, notice some issues with your code, it didn't quite pass muster. Why don't you go back and fix those before I actually commit this, right? So it's taking the ownership of making changes to all the code off of you as the open source project manager and putting them back onto the developer who's actually writing the code. Which again, saves time, makes it a little easier to manage the project.
18:01
Again, on pull requests, it has full support for pull requests. The workflow looks very similar to what we just saw where a pull request gets issued, GitHub sells Travis about the pull request, Travis runs the build and then tells GitHub what happened. Pull request success looks exactly the same. So if you've got your PRs tab, it's gonna show you the same success or failure on the actual pull request that it does for the commits.
18:22
So Travis.yaml, this is sort of the brains of all the Travis stuff. It's your config file. It's what tells Travis what it needs to do, what it should install, how it should run the build process, what should happen if a failure occurs. Everything that you need to know, Travis needs to know about your build should be in this file. And the life cycle of this file looks a little bit like this.
18:41
So you've got an install step, you've got a build step and you've got a deploy. Install is what you're gonna do to actually set up and scaffold your environment. So any software that needs to be installed into that environment should happen during this step. When the environment first gets spun up, there's nothing there. It knows nothing about you, doesn't know if you're running Python or PHP or Node and doesn't really care.
19:00
So you have to tell it what it needs to install. In this case, there's some system defaults for each language. So for Node, during the install step, it's gonna run npm install, which is gonna install all the packages that you have in your project for Node. For Python, I think it runs pip install. So there's some defaults per language that you can check in the docs. And there's also the before install step.
19:20
That's what you'd use if you needed to download like a zip package or something before doing an installation. So if there was a custom fork or a custom branch of some piece of software that you needed to load, you could actually load a tar file or a zip file before installation and then when the install step actually occurs, you can tell it to install that software. The build step, as I mentioned, is this is where like the bread and butter happens. This is where everything gets built
19:40
and it runs your unit tests, it runs your linter, anything that needs to happen to check that project happens during the build step. And it's broken down into a few additional steps. Before script, script, and then there's after success and failure, and after script. Before script is sort of your last chance to handle anything before actually running your build. So if you needed to set up some databases, put some data into them, whatever you might need to do to run your tests,
20:01
it's sort of your last chance to do that before you run the build. The script step again, that's where your build happens. And then after success and failure are gonna happen after a successful event or after a failure event. Travis actually enters and exits on what's called a zero base. So if you report anything other than zero, it's gonna fail. If a zero gets reported, it's gonna pass.
20:21
So you actually have these two events that can let you know whether it succeeded or failed and when you can use those to do any additional steps you might need in your build. So after failure, you might wanna upload some log data to your server to say hey, there was a failure, this is what went on, and upload all the logs from the build. For success, you might wanna send a notification somewhere, you might wanna upload the project to a custom deployment server, whatever you need to do.
20:44
And then after script is sort of the last step. That's what happens after the full build is complete, success and failure have been notified, it's like your last chance to do anything before exiting. Deploy is actually for custom deployments that Travis has created. Again, if you're doing any sort of custom deployments of your own for a service they don't support, you would do that in the after success or failure steps.
21:03
But for deployment providers that they work with like Heroku, Amazon S3, NPM, you can do them in the deploy step and it's just before deploy and after deploy. So the before deploy would be when you'd set anything up again that you needed to do. Deploy is where you actually deploy your code and after deploy is what you do to clean up after the fact.
21:21
So in an instance we'll look at here in a minute, we're gonna actually bump the NPM version, we're gonna deploy it out to NPM JS to update our package with the new code and then after deploy, we're not gonna really do anything but if we wanted to we could send a notification or echo something out to the system, whatever we wanted to do there. So linting, again, this is where you can actually
21:41
enforce some stylistic guidelines to take a look at what that looks like here. Looks much the same as it did before with our simple unit testing but we've added this little tag to the script line here for JSCS source. JSCS is a package for node
22:00
that lets you do linting on your project. You run it from the command line by just doing JSCS source and it'll actually run the linter against your entire project. And you can see here I've got a missing semicolon after the statement so it's gonna give me an error there. If I go ahead and actually commit this up, let's just do, we'll make a simple change here. Let's add a space or something.
22:21
Add everything to the project, give it a little message for break the build and we'll push it up to GitHub. That'd probably help if I used Git instead of bit.
22:44
So that pushes up to GitHub. Again, that's gonna kick off a web hook which is gonna notify Travis. And we'll actually jump over and take a look at the Travis CI site here and see what happens. When you first come to the Travis site, you're gonna see this signup link here. It's gonna ask you to give permission to GitHub and what that'll do is allow Travis to access all of your public repositories
23:00
that you have admin access to. So they can pull in the data and allow you to interact with them from the Travis system. I've already done that quite some time ago so it's gonna kind of jump past that when I click sign up here. And instead it's gonna sign in but you just see something a little bit different where it asks you to grant access for GitHub. So you can see here, here's break the build. When you first come into Travis, it's gonna take you to your most current build
23:21
that's happening. And you can see here, if that's big enough for you guys, I can build this up a little bit. It's actually gonna spin up the build and actually show you what's happening on the environment as it's building. So you can see here it's installing NVM, the latest stable version of Node. You can see the version 6.2.1. It's gonna run NPM install that's during that install step.
23:41
So it's gonna download all the packages. You can see here is JSCS. So that's one of the packages it's loading. It's gonna do an install on the system so it's got everything it needs for the build. It just takes a second here. If we look at the NPM install too, you can see by clicking on these little tabs on the right here, you can actually see more information about what's going on during that process. So for Node, these are all the sub-packages
24:01
that are included in that install. And then you can see here that it's gonna run JSCS source. That's our script block there. And you can see that there's the same error that we have. We're missing a semicolon, right? So this is gonna actually spit back if this was a pull request or a full commit as opposed to just something I'm committing to the branch. If I was trying to merge in to master or something, it would actually spit back that information to GitHub
24:22
and show you the error to say, hey, this is invalid. This is why you need to make an update. So linting's pretty simple to do. Obviously this is a very simplified example, but usually you'd have 10 or 20 more options that would really refine what your linting options are. And while we're on the Travis site, let's look around a little bit. Are you guys able to see that okay?
24:41
It's good, all right. Let's make this a little bigger. So when you get on to Travis, as I mentioned, the current branch is sort of the latest. This is what's been going on with your build. You can see right now it shows me very easily. I've got a big red flag here. There's breaking errors with the build. There's something going wrong. I can look in here to find out more information
25:02
and this is persistent. So this will actually stay later on if I wanna go back and look at what the build information was. This will all be here for me. There's also a branches tab which will show you all the branches available. You can see here the master branch is still passing. The linting branch is actually breaking. You can look back at all the builds and why they broke. And then there's also a build history.
25:21
So this is the full history of every commit, every pull request, every build that's ever occurred which allows you again to go back in time and kind of see what's been going on. And then you can also filter by pull requests. So you can see here's the PRs that have happened in the past and as a developer, if I'm working on this project, I wanna come in and see just what's been happening over the last couple days. I can look through here and see all the pull requests and then go back over to GitHub and decide what to merge.
25:43
There's also a help section here. Actually, I'm gonna look at one more thing here. This little plus tab, I missed this at first. This is actually pretty important. This is where you enable and disable projects for Travis. So after you've added that Travis.yaml file, you've committed it up to GitHub, the last step there is to actually enable it by clicking on this little green button here.
26:02
So I've just disabled Travis for the project. It's not gonna kick off any more webhook events. If GitHub notifies it of anything, I mean, it's not listening basically at that point. Clicking it on, that activates it. The only other thing you need to do, and you don't have to, there's defaults in place, but if you wanna do any more custom configurations, this little gear icon here,
26:20
you've got options for building only if Travis is present. So if that yaml file doesn't exist, you don't have to kick off builds because they're not gonna really do much anyways. You can build pushes or not. So if for some reason you don't wanna build pushes, you have the option to turn that off. The same with pull requests. And there's also, you can limit concurrent jobs. If you're doing a lot of builds and it's taking up too much space and they're running really slowly,
26:41
you can limit how many builds can happen at one time. This is also useful if you're doing what I mentioned with the matrices. So if you're having more than one version within your build and you only want a certain number to happen at a time, it's a good way to go about it. And this is also where you'd set environment variables. So if there's anything that you need to be available in the environment, like tokens for authentication or something like that, you can store those here
27:02
and they'll actually be available in the environment when it builds. And the other section I was gonna mention was the docs. They have a really great documentation site. They've actually got guides for a lot of specific languages. You can see here the programming languages that are available. As I mentioned, there's about 30 now. And there's also language-specific guides for most of them. So if you're working in Java or Objective-C,
27:22
you can actually follow step by step how to make them work for that specific language. And they've got great information on that. This is also where you'd come to learn about any of the specifics of setting up notifications or databases or anything else. They've done a really good job with the docs though. So jumping back over here. So again, with linting, it's very simple to set up.
27:42
You use your JSCS source if you're using Node. For your language, whatever it is, you can set that all up. And then your failures are gonna be reported. So database support. This is another huge piece that Travis did really well in my opinion. They've made a bunch of services for these various databases. So all you need to do is identify the database that you're actually working with
28:00
and tell that in the Travis config file in the YAML. And you'll actually spin it up on the server. By default, these don't get installed to save memory and to save space, make it run faster. So if you tell it you need MySQL, it's gonna install it on the fly before your project runs. So during that install step or just before. So if we look here at, let's do database as example.
28:26
I've updated the Travis.yaml file here to use the services key. I've told it I wanna use CouchDB. You could do Mongo, you could do Redis, you could do MySQL, whatever it is. They all have a little bit of different setup options. And again, those are all available in the documentation. But for Couch, it's very simple.
28:41
You just tell it I'm gonna use CouchDB and that's gonna tell Travis when you spin up the environment, I need you to install CouchDB so it's available to me. On this piece here, Couch actually uses HTTP requests to set up their databases. So I'm doing a curl and then telling it the use the put header type. And then I'm gonna call out to the database. This is the path. And just say I wanna set up this database
29:01
called Travis node demo. The second part here is actually just gonna call out to this all DBs endpoint. And all that's gonna do is return and say what DBs are available. Basically ensuring that we know and spitting out to the command line that our database was in fact created. So we ran that. That's really tiny.
29:21
It looks something like this. Spit this up a bit. So we get back from the Travis build cycle and that step that we saw a minute ago. You'd actually see, okay true was our response from creating the database. And then if we pulled and saw all DBs, we'd actually get this back. You can see the Travis node demo of the database is now available. Now this is done in the before script step.
29:44
That's the step that happens right before the build actually gets kicked off. So again, you're gonna need the databases available for any testing you might do during your build. So you'd wanna do this in the before script step. And this is also where you do any additional things like adding data to the database or populating it with information, whatever you might need to do there. But again, this works much the same
30:01
for any of the databases you might be working with. It's a very simple process. So the Travis clients is worth mentioning. They have a command line interface client. I think it's RubyGym and you install it through whatever package manager you might use for your system. I used Homebrew to install it I think.
30:22
And the command line client lets you do things like encrypt your keys. So as you look at adding new services for notifications like Slack, which we'll look at here in a second, you can actually encrypt the keys that you're gonna store in your Travis file. So you don't have to worry about handling that yourself. Travis has a method for doing it through the CLI. It also lets you do things like lint and test, verify, validate, whatever you wanna call it,
30:41
your Travis file. So I've got it installed already and it's just run under Travis. So if I do Travis lint, it's gonna look for the Travis.yml file and just validate that that file is actually valid. So you can see, hooray, Travis looks valid. We're good to go. If there's any errors with the file for formatting or keys that it didn't understand, it would actually report them here
31:01
and let me know what's going on with it before I uploaded it. So it's great for debugging. And as we'll see in a minute here, you can also use it to add information to your Travis.yml file. So deployments, I mentioned, Travis has a bunch that are currently available and they're adding more all the time. Some of the big ones, Heroku, NPM, PyPy, Amazon S3, RubyGems and GitHub.
31:22
So as you're managing your projects, that was something else I found quite painful is every time we did a new version of the, or a new build on the project, we'd have to push it up separately to NPM. And I'd have to manage that myself. So every time somebody did a pull request, I committed the code in, we merge, we had a new version to do, I'd have to do an NPM update, update the version, then I'd have to push it up to NPM JS. It took a lot of time.
31:42
So luckily, Travis has an easy way to handle that. So again, we're gonna use this before deploy, deploy and then after deploy steps. These are only again for the custom integrations that Travis has actually built. If you're doing something like your own integration service, or rather your own deployment service, like you wanna deploy it out to your own server,
32:00
you would do that in the after success or after failure steps. But for the integrations that they have, we're using the for deploy for NPM version patch, that's just gonna bump the version from when we have a commit. And then after that, we're gonna use the deploy key here, we're gonna list the providers NPM, supply the email address that's for the account holder on NPM, and then we're gonna give it our API key.
32:21
Secure here just tells Travis that you actually encrypted your key using the Travis linter, so it knows to decrypt it before it tries to run it. And then the last piece here is on, you tell it when you want it to actually push these builds. So if you want it to push for tags only, you can say true. If you wanna push just a specific repository, in this case, this is the repo we're using, and if you wanna use all branches
32:41
or maybe just your master or your production branch, you can set that up as well. So there's a lot of configuration options for when it will actually push out your new version. So you can fine tune this however you might want. So we can take a look at how that actually looks in the project. So you can see here, I've still got my CouchDB, I've still got all my information for cURL
33:00
and installing JSCS. One other thing that I found that was a particular issue for me, there was no information in this in the docs, this was kind of a stumbling block at first, is I had to add my global email address for GitHub into the before script key. And the reason I had to do that was because NPM actually looks for that when you push up the build.
33:21
Or rather, when you're doing a commit to NPM from the command line, it looks for your GitHub email address. So I had to do the git config global for user.email and then I also used user.names that actually tags that commit to NPM with my name. So if you run into any issues with deployments, look for the global configs for the GitHub account
33:41
and there might be a problem there as well. Again, here's the before deploy. So we're gonna list out the NPM version before we patch it, just to see what the current version is. All that's gonna do is spit out the information to the command line so we can take a look. And then we're gonna run a patch to update the version. Afterwards, we're gonna actually call out to NPM and here's my secure token that I was talking about
34:01
and it's gonna push out the latest version. If I delete this real quick, I can show you guys what the Travis Linter looks like for this. So you do Travis NPM. They have a number of these available for various providers. It makes setting them up a lot easier than having to punch that information in yourself.
34:20
What is the command? Guess we'll get a good look at what's available. No, it's not listed. I just used it earlier today.
34:42
All right, well, so here's the easy thing. We'll get a better look at the docs. If we just search for NPM, it's set up NPM. And again, they have these deployment guides for all the various deployment services that they work with
35:02
so they're really helpful. So if we do Travis set up NPM, deploy section already exists so it's gonna notify you if there's already a section in your file. So if I just hit save there. So it's gonna ask for my NPM email address.
35:22
For my API key, I'm just gonna make something up here. And then whether or not I wanna release only tagged commits, that's kind of a helpful feature if you use tagging as part of your release process. Release only from this project, yes. No, I wanna release all branches.
35:41
And encrypt your API key, yes. So what this is gonna do is actually add that section. The unfortunate part is I like to format my stuff a little bit differently than Travis, but it actually does a cleanup on your whole project. So you can see it's changed everything so that the lists all start on the same line. There's no tabbing to actually make this a little bit more readable. But you can see here,
36:00
it's out of that whole deployment section for me, which is really useful if you don't wanna read through all the docs and have to go through adding all this stuff by hand. So yeah, you end up with your deploy section. There's a bunch of those command line tools available. So if we just make a quick change here, take a look at what this looks like.
36:21
Message, deploy. So we're just gonna push up a simple change just to kick off the deployment process so we can kind of see what that looks like. If we go back to Travis CI,
36:46
you can see it's still, now it's showing the deployment. So sometimes it'll show, it'll be a little bit lagged behind, and it'll show the last build for the current. If you run into that, I usually just go to build history, because you'll be able to see, even if the build is still taking place, it's always shown here. So if the current isn't showing you
37:00
the current build that you think should be running, you can always check it here as well. So if we click into that, we'll be able to see the build running. So right now it's cloning out the Travis Note Example repo. It's installing CouchDB and running the process.
37:24
Now it's updating NVM, and it's gonna install Node. Just bear with me, guys. Sometimes this takes 30, 45 seconds. It's downloading everything it needs for Node. Now it's running NPM install to install the packages for our project.
37:46
You can see there's that git config I mentioned, so it's actually setting up my global git email address and name in this environment, so it's available. Then it's gonna run our unit tests with, or sorry, our linting with JSCS. It's gonna set up that database.
38:01
Then it runs our tests. Our tests all passed. So, so far it's made it through. You can see here's that exit with zero, which means it's a passing build. Now it's installing any dependencies for the deploy. That would be the b4 deploy step that we talked about. And you can see here again, this is really useful stuff on the right. If you click through on these, you'll see some additional information. Obviously we didn't install anything for the previous deploy or for pre-deploy.
38:23
Preparing deploy, you can kinda see what's going on behind the scenes. So it checks the NPM version. It authenticates to NPM before we can push this all up. Then does a git stash. So if there's any changes that occurred actually within the Travis environment, it's gonna clean that all up before pushing it out so you don't have a bunch of remnants or files that aren't needed
38:41
being pushed out to your build. Then it's gonna update the working directory and push it back to GitHub. And you'll see there that it deploys the application. So it's worth noting again, these little guys on the right here, because I had some times where this was actually failing for me. The deploy was failing because I hadn't bumped the version number on my local repository
39:02
and I tried to bump it here. And so essentially what was happening is that I was updating it to the version that was currently on NPM. It was already released. And in doing so, it would actually fail. But it was failing silently because I didn't have these expanded. So it would say deploying application and everything looked great. It doesn't look like there's any issues. But in clicking this, I would actually see there was an error in the deployment process.
39:21
So again, if you're pushing something out to a deployment service and it doesn't seem like it's working for some reason, you can't figure it out, pay attention to these little tabs on the right and check out if there's any additional information available. But you can see here this deployed out to NPM. And the version we're at now is 1.0.11. So we bumped the version. Now if we go over to NPM and it was previously at 1.0.10,
39:42
we do a refresh. There's 1.0.11. So again, this could have been a pull request or a commit from another user. And given my requirements from Travis, I could have built the whole project, verified it and with no hands on at all, I could have pushed out the project. So you can start to see how this would save you a lot of time and a lot of effort in managing your projects.
40:08
So notifications is another really cool part. There's a lot of options for notifications with Travis. These will let you know when a build occurs. You can set it up to tell you when a build fails or when it succeeds or when it starts. You can really fine tune it to do whatever you want.
40:21
Some of the available notification stuffs, email, IRC, HipChat, Slack is a big one and webhooks. Webhooks are really useful if you use any custom webhook stuff in your own company or in your own environments. So if you wanted to set up some custom integration with maybe Twilio to send you a text when a build happens for whatever reason, you could set up some sort of a DevOps tool to do that.
40:42
So the notification section looks just like the rest. It's got an identifier of notification. Underneath that you can set up email, Slack, IRC, whatever you want. For email, it's on by default and it's actually gonna push it out to the owner of the project on GitHub. So if you're the admin for that project, it's gonna notify you by email by default every time a build succeeds or fails.
41:01
You can customize this to send it out to any recipients you want or to change your email address. So if you wanted to go to your personal email address instead of your work email address or something like that. Or if you wanted to add additional recipients, you do that all here. We can look at this in the project as well.
41:20
So you can see here's our notification section. I've got the recipients list set up to just my personal email address, but if I wanted to say also send it to my work email address, I could just add it to the list here and then it would send it out to both of those addresses on my options. On success and failure, I've got them set to always, so it's gonna send me a notification no matter what. You can also set it to never.
41:42
So if you just don't care about failures or if you only wanted to know about failures, you could turn success off. And then I've also got a configuration here for Slack. Just to look at that real quick on how you set that up. You go to whatever your Slack channel name is, .slack.com slash apps. This is where you install applications and this is all in the docs for Travis as well.
42:02
But there's actually a Travis CI app. So if I just go look at the Travis CI here, you'll see here's the Slack channel that I'm working with and I'll just say install. It's gonna install the Travis app for Slack, which makes it really easy to set this all up. And then I'm gonna choose a channel. So I'll just go with build notifications. It's a channel I'd set up previously
42:21
to handle all of my notifications. And then just add integration. I was particularly impressed with this whole process because it made it extremely simple to copy and paste this stuff into my config file. So you can see here, if I want just simple notifications, I can copy and paste here. If I want to send it to more than one channel, I can copy here. If I want to encrypt, this is the actual command line client for adding these using the Travis CLI.
42:43
So it'll actually take my token and my channel name and then it gives me the full line to paste into my command line just to encrypt that data and add it to my config file. So if I ran this, it would actually add something to my Travis file that looks like this. It would add the Slack piece for me and the secure encrypted token for my Slack channel.
43:03
So this will start giving us notifications then. Every time those events happen. So again, for emails, it's gonna look something like this. In Gmail and Inbox now, they're actually tagged red and green so you can see based on failures or success right on the way. And again, this helps you manage your project. And then Slack, this is really helpful too.
43:22
So if you set up your own Slack channel for your project you can actually monitor these throughout the day and know when something goes on. So if a build gets committed and you see red, you know that you can click through and just go back to that commit and say, hey, this is why your project failed or why your commit failed. Maybe make these changes before committing and then push it back up. And again, this is really placing that responsibility back on the developer who's committing the code
43:41
rather than making the project owner be responsible for everything. With the goal again of saving time and making things a little easier for you. One last thing is build status badges. This is actually kind of a fun feature. And once you start looking for these things, you'll see them in almost every GitHub repo. This is sort of the telltale sign of the fact that they're using Travis.
44:00
To add these, it's very simple. Let's go to, actually it's right here. So you can see this build is failing. And I didn't find this at first. I actually had to look in the docs for this. But you just click on the little icon here. And they have available some really nice options for this. So if you just want a straight image URL or if you want to grab it as markdown
44:21
to put it in your GitHub readme, they have it as rdoc, rst, ascii doc, all these options. So whatever you're using in your builds, you can actually grab these and append this. So for GitHub, you just add it to the readme at the top and you'll end up with something that actually shows you the current status. You can see here I've got it in my project. Build's currently passing for the master branch.
44:41
And this is just a great way to notify your developers of what's going on, as well as just notifying yourself. So again, the whole point in this is to make open source fun again. Managing projects should be fun. They always start off as this kind of great joy. You're putting this project out there in the wild. You're helping people with stuff. You're sharing your code and really sharing a part of yourself.
45:01
So by adding Travis, I'm really hoping that we can kind of make this process a little bit more streamlined, save some time, and make more fun again. If you guys have time on the way out, please leave some feedback. It's always helpful to us as speakers. Really appreciate that. And thank you guys so much for sticking around. I know it's the end of the day. It's the last session of the conference. You guys are the hardcore few.
45:20
So thank you so much for coming. And I'll be around for QA if anybody has any questions. Do we have any questions? I have a comment. Ah, OK.
45:47
How many, not developers in the audience. All right, so the one guy. Two? Yeah, I'd say like 70% of the people I met at this conference were .NET developers. That was actually really useful. I was reading up on that today,
46:00
but I wasn't familiar with Mono. Is that a build process? OK, so you can install that on Linux then? Gotcha. So for those of you on the recording, if you couldn't hear that, yeah, he's saying there's some information in the docs
46:21
for Travis on using Mono to build your .NET projects. And again, from what I've been told, they actually are working on native support for .NET and Windows platforms. I just have no idea when it's going to come out. I actually pinged the Travis team earlier today to try to find out, but they didn't get back to me quite in time. So hopefully we'll see that in the future.
46:52
Yeah, yeah, so the point he was making is that the new ASP.NET core and the core system makes it available to run on Linux, right? So the fact that that's open source
47:01
should make the integrations easier for the Travis team, and also hopefully make it a little bit faster for them to release that. That's a great point. Questions in the back? All right, guys, well, thank you so much again. I can't tell you how much it means to me that you stuck around for this. Thank you very much. Cheers.