hello everyone and welcome to anotherDevOps comm webinar thank you forjoining us today we have an interestingwebinar with open making github learn tobe talking a little bit about theapplication package from githubrepository called deploy hub and they'regonna show you exactly how to do it howto deploy it and get it done on thatnote let me introduce you to both Tracyfrom open may open make and Christianfrom github Christian are you there I amthank you I want to take over yes yourcan thank you so much okayChris are you there Christian I am areyou are we ready we're ready take itfrom here all right thank you so much sothank you guys for everyone that'sjoining on this webinar this afternoon Ijust want to give you a quickintroduction to myself my name isChristian Weber I'm a SolutionsArchitect at github I've been withgithub for about two and a half yearsnow and my previous experience I spentthe last six years prior to github infinancial services I have doneeverything from release automationrelease engineering release managementto various levels of level 1 throughlevel 3 support and have really seen alot of ways I've really seen theevolution of software development intowhere we're seeing today so really whatI want to cover with myself and Tracy ishow we can leverage an automated processwith software delivery into a tool withopen make as well there's a lot that wecan cover in this conversation butreally what I want to drive home todayis the spirit of collaboration amongsoftware developers and using tools likeopen mic to automate the deliveryprocess as quickly as possible so withthat I want to go ahead and have maybeTracy introduce herself and then we'llgo ahead and get into the discussionthank you i'm tracy reagan's CEO of openmic software what we're talking abouttoday will be a product that is nowknown as deploy hub and it's itsspecialty is being driven by the CDprocess to do continuous deployments weoften hear that continuous deployment isthe sort of the unicorn well we we thinkthat you can you can you can leash theunicorn and put it to work for you andthat's what continues to appointmentsare all about well talk a little bitabout some of the challenges but I wanteverybody to understand that applicationrelease automation does not have to beexpensive deploy hub is open source sowhat we're going to show you today youcan actually get started with at no costto you and Christian I'll turn it backto you perfect and for those on thewebinar Tracey will be my guide with theslide so you may hear me say next slideso that's what that is so as Tracy wastalking about you know essentially whatwe're what we're thinking about here issoftware development from two sidesright we're thinking about releaseautomation and release management we'realso thinking about github as a softwaredevelopment platform that can sort oflink this whole process together so whenwe think about traditional softwaredevelopment life cycles you know one ofthe last pieces that's really to besolved in this process is the idea ofhow we can sort of manage continuousdeployment we've done a really great jobof managing a software developmentpipeline up until the continuousintegration point but up until now therereally hasn't been a lot of great toolsthat really can handle sort of releasemanagement and sort of the next stepfrom there as well so when we talk aboutteams that want to be agile or they theywant to sort of accelerate the releasecycles essentially we need an end-to-endpipeline that can give it get us all theway from development to production andso when we think about those thattooling what that will enable us to dois to bring us into a cycle ofinnovation tracing next line perfect andwhat I mean by that is we need to getinto a mindset where we are moving awayfrom ideas like long-running branchesand and long-running releases andgetting to more of an iterative approachregarding our change steps need tobecome smaller and smaller because whenwe do something like that then we canactually start making more rapid changesto our product just as an aside we dothis internally at github and thisallows us to release production 15 15 to20 times a day to github.com and the waywe do that is through this sort ofprocess that you see on the screen so aswe're walking through this I'm going tofocus more on the github side of thiswhich is our sort of continuousintegration into our code and thenyou'll see on the right-hand side thatwe're actually moving into you deployhow to manage our shift code as wellthis sort of cycle again producesinnovation and produces amore empowered developer because whatwe're really trying to do at github iswe're trying to change the context ofhow software development is done tracingX licenses and what I mean by changingthe context of the conversation is thatwe want to build more communities withinsoftware development organizations tochange that context when we think abouttraditional software developmentpractices a lot of times traditionalsoftware shops have written software insilos they've written very regimentedvery isolated pieces of software thatmade will link to a bigger picture but alot of times and organizations are notnecessarily on board with are notnecessarily given the information as towhat the bigger picture is so when wethink about a platform like you have toenable that I think one of our casestudies with one of our enterprisecustomers sa P really shows that whatwe're doing is we're breaking downinternal silos within softwaredevelopment organizations wereincreasing transparency and with thiswhole process where we move into a shiftleft mentality we are now exposing allof that all of those changes within thescope of that organization to all thosedevelopers this again kind of moves intoa concept of what we like to call intersourcing with art within organizationsin that we take the practices andmethodologies that have enabled theopen-source software developmentcommunity to succeed with largedistributed projects and start applyingthat behind our firewall so what I meanby that is that we do things like moveinto a method of being opened by defaultmeaning that if I'm a member of anorganization within my github instanceunless there are specific legal orcompliance reasons that prevent meseeing that code repository should beopen for everyone to innovate and workon from there as wellTracy next slides because when we startdoing that in terms of building thattransparency and that visibility intothat pipeline what we can't see throughindependent study is that this actuallyreduces developer churn and increasesvisibility so I'm not sure if a lot ofyou are familiarwith a good time but essentially theyare get these research organization thatdoes a lot of metrics and a lot ofsoftware based on git itself and theyfound that developers that have gone togithub from other legacy systems onaverage reduced code churn by at least12% depending on the organization so wecan already see that from from a metricstandpoint there's already a tangiblebenefit my developers moving into thismindset and when we start reducing thatamount of churn we do two things one wereduce the amount of work that adeveloper has to do and we're alsodecreasing code deduplicationas well I can tell you firsthand thatfrom in a previous life when I worked ata financial services firm you know oneof the biggest challenges that we had asour own organization was really thatcode deduplication effort because we hada lot of isolated teams that didn'tassume there were at least two projectsthat I worked on personally where had Iknown what the rest of the organizationwas working on we would have been ableto we would have been able to increasethat as well so now I want to kind ofmaybe shift the conversation a littlebit and kind of show you what thisactually looks like on our platformbecause when we talk about the platformwe're not necessarily focusing onindividual features right we believethat the github platform based on allthe small things that make up it reallyaccelerate software developers to workbetter together so when I talk aboutthat it's things like our issues rightour lightweight issue tracker thatallows developers to increase visibilitythey don't have to necessarily switchcontext into other platforms they haveeverything right here I'm Tracy if Icould have you hit the next slide or thenext transition yeah so things likeguidelines right when we think aboutlegacy version control tools you don'tnecessarily have like a really niceplatform that kind of gives you thathelps you sort of lead the way and leavebreadcrumbs on how you want to do thisso one of the most important I thinkthings I think when we're looking at thescope of a repository on github is theguidelines and the contributingguidelinesdevelopers and users of that repositoryyou can see from there as wellnext slide think other little thingslike labeling that allows us to tagthose two milestones which then we cancut from releases really allowdevelopers to not only organizeefficiently but also allows newdevelopers to really organize and seewhat they can contribute on a verycommon use case with developers that areusing github for the first time is thatthey'll go into a repository organizedby the labels and look for labels likeeasy to fix or first-time contributorbecause they can see what kind of issuesthat they can fix on there as welltracie next buttons and then we moveinto the idea of the pull request nowone of the most important things that Ithink when we think about the pullrequest is that were one you knowputting version control in all of ourcode but the second thing that the floorrequest does is it encourages andexposes collaboration across the entireteam so this is an actual pull requestthat's on the github slash github thatis currently open so we're fixing a nicelittle bug within one of the PR edittitles and you can see that you know wehave we have developers that arecollaborating on the code as close tothe code as possible because when wethink about a traditional softwaredevelopment a lot of times our changerequests and our conversations aroundour code or happening in disparatedisconnected systems that don'tnecessarily allow for the context to beshown in the future so if I was to lookat this PR six months from now because Ihave that conversation right there I cancertainly understand the context ofmaybe why this code was changed or howit evolved over time the second part ofthis and going into where Tracy is goingto take over is the security and thecontinuous integration that's built intothis process as well so even if I havean approved pull request as I have righthere and all of my CI has passed webuild this all into our pull request andwe can certainly allow for any level ofgranularity on there as wellright Tracy next slide because thenwe're also going to build in the idea ofcode security so even ifyou know all our CI checks passed andall of our collaboration all of ourapprovers have reproved it we can stilldo things like code security to preventcode from being merged until we'reabsolutely ready and I think that reallyties into this whole process and how wewant to build an automated pipeline andthen integrating into tools like openmake and deploy hub that will integratethis process and accelerate it evenfurther we at github know that we do youknow one thing really well which is ortwo things really well its source codemanagement and code collaboration wethen work with our integration partnerslike deploy hub that can really takethis to the next step and with that saidI'm gonna go ahead and hand this over toTracywho's going to lead the rest of theconversation today yeah Tracy this isParker let me interrupt you for onesecond everyone just to let you knowwe're gonna have a question and answerperiod at the end and this webinar willbe available for viewing on DevOps commafter the webinar if you choose to viewit againTracy toy yours okay yeah Deb we haveour first polling question 45 percent ofFortune 100 companies you githubenterprise are you gig github enterpriseuser yeah I think this was one of themost interesting things I learned when Ijoined github you know when I when Ifirst joined github about two knifeyears ago while it runs polling I didn'teven realize we had an enterpriseon-prem product and as its evolved youknow it's really great to see all ofthese you know all of our all of ourusers that use on-premise well so itlooks like we've got a good good mix 61%are not github enterprise users but 39%are so that almost matches where we'reat in the fortune 100 as well okayokay so we're going to continue thisconversation on from where Christianleft off we're going to talk a littlebit about the pipeline and where most ofyou may be some of you maybe have a moremature pipeline but for the most partwhat we see is a process where you havesome level of workflows maybe ran byJenkins or even built into githubwhereby you have a process for dev aprocess of FERC for a testingenvironment and you can get it toproduction and what we see often timesis there's a lot of automation beingbuilt around the pipeline but when itcomes to the package and deploy processit's scripted and for good reasonbecause these tools can be extremelypricey and way over a project team'sbudget but what that eventually will dois create a barrier to getting toproduction because a scripted deploymentcan be a bit tricky to manage across thepipeline they have to adapt they have tochange on the environment and that'sreally what release automation solutionsare intended to do again what we see isthe barrier to getting there is the costof these tools and so what happens iseach environment scripts their ownprocess and sometimes dev will scriptfor QA but it for the most part it getsstaged and and the production team makesthe decisions at some later point whenthat when that code gets moved all theway to the prod State it's notnecessarily automated or pushed in acontinuous delivery fashion part of thereason too is a trust factor productionteams like to write their own scriptsjust as developers like to write theirown scripts and sometimes testing sowhat occurs is that a production teamlooks at the development code assomething they can't maintain and sothey choose to write their own sothere's a trust issue in the in theoverall process and what we're reallytrying to get to is a mature loop onethat information can be shared acrossthe pipeline and as a christian pointedout we want to shift left so more of theresponsibility for doing deploymentsneed to be in the hands of thedevelopers because quitesee it's the developers who know themost about their application and theyhave the most to lose if something goeswrong and in reality for years now wehave had developers helping productionteams to get their production scripts towork so we really are trying to build aloop and we're going to show you butbasically today how you can do that solet's just get another poll here youknow how mature is your continuousdelivery model are you in one of thesecategories where each environment ownerscripts their own deployment practice orwhere your CI CD manages scripteddeployments all from dev to test and thethird option is are you using a fullrelease automation solution Deb I'll letyou go ahead and open that poll okay Ican't see them Deb is there anythinginteresting there you want to talk about44% say each environment owner scriptstheir own deployment process followedclosely at 31% with CI CD managesscripted deployments and 25% you use anintegrated application releaseautomation system so some of you havematured up to that highest level whichis where most companies are trying toget to and several of us are still backthere doing what we can with the CI CDprocess so I I think that you'll seethat the you know automating thesepieces it continuous deployment is ascritical as automating continuous buildand continuous test so we're gonna lookat are you guys are still able to see myscreen does it advancing yep okay thankyou so the tools you're going to needwe're going to show you how to use thegithub repository for the issue trackingand and keeping track of the theartifacts to be deployed and deployedhub for doing the release packaging andthe and the actual release process we'regoing to keep it down to two simplethe first step what you do is you createa deploy have application package usingcomponents now in the deploy hub world aapplication is made up of multiplecomponents those components are mappedto the yet the github repository at theartifact level and at the issue level soyour your mapping first your your assetsyour get your github release assets to adeploy web component so that makes yourfirst connection the second step you'regoing to do is create a pipeline projectso you're going to use your githubproject to control the deploymentsacross the pipeline but you're going topackage the deployment in a deploy webapplication so for example a deploy aapplication package might contain twocomponents Tomcat web app Runner andenough time war file now you couldinclude also other parts of thatapplication like the database forexample if you had database changes thatwould be a component if you need toinstall a tomcat you could actually callan Ansel Buller which we integrate withour puppet to actually or chef toinstall Tomcat and what the pipelineproject will do is to help manage theapprovals for the deployments it willrecord a full audit history so you havea the ability to have a loop and havevisibility for your production teamsit'll consolidate all these deploymentactivities so they're in one place andthey're actually versioned and they'regoing to link deployment components backto a change request and what that'sgoing to do is give us a full full loopso that everybody can stay in in theloop so to speak now the results will bea wiki the wiki issues are going to belinked to your deployments so you'd beable to go into your your your actualissue and you'll be able to see if it'sbeen deployed and where it's beendeployed to and all that information ishyperlinked for easy viewing so you canactually look at a change request anddetermine what deployment that changerequest was a part of and be able todrive down and actually see what whatwhere that deployment might have beenand how far across the pipeline it itgot to so what you're ending up with isa full loop starting with being able tocreate those github web hooks that tailsdeploy hub to check the approval statusand records any corresponding approvaland deploy hub I'm just going to go downthrough that the approval process sodeployer would move a package theapplication package with all thosecomponents from a developmentenvironment into a test environmentexecute that deployment with any postaction for example you might have a postaction to run test automation and thennotify everybody on on success inparticular production at that pointproduction can approve it and move thepackage up the tooth of production stateexecute the production and execute anypost action and we have customers whooftentimes like to do a smoke test inproduction now keep in mind that formost of this it's quite it can bemanaged by the development team or yoursite reliability engineer the the wholeidea of shifting left means thatdevelopers have a tool that productionand testing team can have visibilityinto and have some control if they needto and that's that's what the deploy hubgithub combination offers so again whatwe end up with is the with github anddeploy of having all the information inthem so you can go to that wiki page andcentralize what they continue continuousloop look like from the initial approvaland then the check-in all the way to theproduction deployment and all theactions are recorded in both locationsthe deploy have actions the build logsthe test results in all the changerequests on the deploy web side you'regoing to get a full continuous feedbackloop as well which shows you all the wayback to the source and they get commitswhat build job if they if you're using aCI server like Jenkins you might bring abill job forward the issue numberassociated to the application componentsthe application package all the way tothe environment and the endpoints in theenvironment so now you thought youactually have the ability to say I knowI committed my code I know we did a billbut did it ever get to production andthis provides that full loop now theloops not just important to developersit's important to the production teamsbecause what the production teams wantis not necessarily the responsibility ofdoing the deployments what they want isthe the the information and thevisibility into what's occurring andthey also want some level of controlwe didn't we're not talking about ittoday but calendars can provide themadditional security and control aroundthe process but we're really talkingabout the open-source version and in theopen-source version the production teamhas the full visibility into what theyneed to know about that that releasethat went forward in back inside if wego back to the to the github wiki we cansee that all of the feedback loop logsso you can see everything that occurredfor that entire process from thebeginning of the pipeline all the wayback to the beginning of the pipelinewhen the changes are done again so justa couple of points what we used we usedweb hooks for triggering events we usedwhat we call releases for managingartifacts we use the github wiki fordocumentation we use the githubEnterprise security model for lockingdown who can do what and for auditing ofwho did what and win on the deploy webside we deployed by those events we hadwe used application packaging forcomponents we used our what we haveinternally in our continuous deploymentpipeline and we use some pre and postdeployment actions we used they get arepo for pulling the artifacts and wedid our own versioning control in thatprocessso just to since some of you may notknow what deploy hub is it's anagentless continuous deployment solutionit has an open-source base to it thatcan do what we just talked about whatwhy is important is because it allowsdevelopers to declare theirconfigurations of their applicationpackage including database andinfrastructure and it also allows thatthe the application package to be pushedor pulled so you can have a pushmethodology in that as you wouldn't acontinuous delivery or an on-demand pollif you chose to do that and it contractto any kind of target physicalcontainers the virtual might these thisthis topic is going to become more andmore important as we go to microservices and what's running on a microservice and it has an agentlessarchitecture so it's super easy toinstall and implement and it doesn'timpactor is it's non evasive when itcomes to the production environmentyou're not having to ask your productionteam to install agents in order to makeit work another important part that youknow as a selling point as a developerto get this moving forward to theproduction team as it does have aback-end version control database not toversion the code coming out of github ofcourse but to version the package itselfso once you declare your package all theway down to the logic required to do theinstall for any particular component oran update to a of environment variableor a change to a Cisco request routerall of that stuff is kept in one packageand any changes made to it no matter howsmall is recorded personally I thinkit's the most interesting part of ourproduct because it does provide theability to do version jumping so forexample if you've got production is backsix or seven versions and you need toget them up to speed up to the mostrecent version it's going to do that foryou but it's going to do itincrementally even pulling all of thedatabase pieces in any of theenvironment variable pieces along withit as I said you don't have to go outand get budget Authority for usingdeploy we have to do your continuousdeployment we saw that there was a gapin the PI in the open-source tooling fordoing continuous delivery and continuousdeployment so we stuff that with deployhub it competes extremely well againstthe big players and we have beenrecognized in the Gartner Magic Quadranttwo years in a row and we continue tomoveto the to the east and to the northwhich is the direction you want to goand if you want more information you canjoin the community you can go to deployorg and this there is a full demo ofwhat we just talked about and you canfind that at OPA make software calm andon that note I think I will leave itopen for questions yeah Tracy I'm backI'm sorry have to apologize I had somemic problems but so I sort of left youhang and DEF picked up the poll questionso thank you Deb but anyway we have somequestions and let's start is we have alot of time so this is going to be realinteresting we really get we can diginto this how does the whole process howdo you start it how do you kick it offwhat's the best way to go about thisTracy I'm gonna leave that one to FERCChristian oh there's a it's a reallygood question so there's a couple ofways that we can approach this rightI'll talk about the more traditionalsort of thought about way in terms ofhow you can sort of clip out anautomated pipeline and I'll say I'llthen I'll move into sort of the githubrecommended way and then the way we doit actually as well so the most commonway that when we think about these likepipelines is we tend to think of it inthe composing situation right I have acanonical source code management serverit can be it can be subversion it can beclearcase and traditionally what mostorganizations I've seen done what I'veseen in my experience is before theyeven think about modernizing they tendto have a build process that will thenquery the source code server for changesright this becomes very inefficientbecause then essentially what happens isyou start scheduling everything andyou're sort of dependent on thatscheduling to have your builds happen inthis process and what tracy and i haveshown and how we actually do ourinternal bill to get out as well iseverything is api and web hook drivenmeaning that in the scope of our pullrequest or even be as granular as theindividual commit we're actually kickingoff build every time somebody commits tothe repository now that doesn'tnecessarily mean that you have to dobut with the flexibility of our webplatform you can trigger events verycommonly so like yeah for example whenwe're getting ready to do withdeployment internally a github we havelike a series of about 20 checks that gothrough and they do that individuallyper commit to make sure that everythingis up and running Tracy in yourexperience what have you seen and how doyou guys recommend well there's athere's a point in the life ofcontinuous delivery that we becomeimportant so for the most part what wesee is that the customer has gonethrough what you've just described andthey believe that they have a they areat a point in a maturity level acrossthe organization that they're reallyready to start mastering what I call aJAL's last mile which is getting thingsall the way to production once thatoccurs that next step is to really startdefining the application packagingprocess it's important to get theapplication packaging down becausethat's what you want to be able toversion and it needs to have someautomated behind it so once they'vegotten to a certain level of maturityand their continuous delivery andthey're probably doing continuous tobuild and they're doing their check-inand compile which is continuousintegration and they're doing theautomated builds and they're starting todo automated tests the continuousdeployment question becomes importantand at that point you have to decidewhere you what's going to drive it inthe demo that we just examples we justprovided github would be driving theprocess but you could also drive it withsomething like a Jenkins the AI processor bamboo or any of the any comments CIserver that you might have yeahand then one thing I wanted to knowbecause I think this is something that Ialways hear in terms of objections fromsoftware development organizations thatare coming from legacy tooling orlatency processes a lot of times they alot of customers will see this sort ofprocess like something like it couldhave an open make and we always do a lotof demonstrations around webapplications or like Tomcat servers arelike even github where you know I liketo describe where a ruby unrealon absolute steroids right so a lot oftimes a lot of organizations will get itin in the mindset that they think thisis only for like web applicationdevelopment or modern softwaredevelopment technologies and the answermy rebuttal to that is we've seen notonly are these tools agnostic but we'veseen successes in just about any sort ofindustry in any vertical so you know Ithink a really good example of this isBMW is one of our enterprise customersin based out of Germany and I think weall know who BMW is they've got greatcars they started their githubenterprise journey because of the lackof great software that was built aroundthere in - entertainment systems so theyevolved onto that and then they haveeventually moved to get their enterprisetheir enterprise software deliverypractice with github and other toolsinto github itself so now they're doingall their embedded development andeverything around every other piece ofthe car is actually being done in thatprocess so it's really about findinglike not only migrating your SCM toolsbut it's also about getting your buildtools and your delivery tools into thisprocess as welland I would say it's not impossible I'veseen a lot of success of it so wellthank you very much you both you getquite the answer another question - isfor you Chris how can you manage adatabase as a part of this process so onthe database side we get that question alot a database is just another componentin the mind of deploy abso we talkedabout what an application is anapplication is collection of componentsand when you define your applicationpackage you would you would define alet's say a P SQL statement is one ofyour components and that that thatsequel statement might add a table forexample to roll forward or it mightdelete that table on a roll back so whenyou're managing databaseopponents you're actually adding them asa component to the application packageand that component has an a activityassociated to it that actually does whatthat component needs and that's how wedo it and so it just becomes anotherpart of the application package it canmove forward or move back or be checkedin to the backend version controldatabase to be checked out and appliedat some future date in an inversion jumpforward or back okay thanks now I'm noteven a guest this time how how do I knowwhen the issue has been closed in whatenvironment it has been installed to Ithink I'll give that to Christian youknow I was gonna yeah what we're doingwith what Tracy showed and what we sortof have is an extensible platform thatcan sort of set up the the granularityand the level of reporting that you wantso in Tracey's example all of the issuesare being linked back in a wikireferencing the issue that it's comingfrom so the way that we key that up isbased on the shoc number that we'rebuilding or releasing off of so Tracytakes that information from our webhooks and essentially takes that JSONpayload and will then report back to thewiki now the nice thing about that isbecause of those web hooks and theamount of information that we give youit doesn't just stop it may be puttingin the wiki it's really up to you on howyou want to build this process so if youwant to be super automated a very commonuse case would be once I have adeployment out then I can essentiallyvia the API close out an issue or mergea pull request back into master if Iwant to as well I would highly suggestfor the person who asked this questionto take a look at our API and see howflexible it is and the amount of datathat it will give back to you because Ithe world is essentially your oysterwith this in terms of what you can do interms of building automation I've seen alot of organizations go automated allthe way to QA but still want to have aa manual workflow from you a to protectyou a t10 production but I've also seenlike what we do again how poor fullyautomated all the way to production aswell it's because of our API and our webhooks that really allow for thatflexibility and that freedom for yourorganization to make the choice on howmuch automation that you want in thereas well and then deploy hub allows youthat freedom or that safety net to beautomated but still have an applicationand a platform like deploy hub to giveyou that safety and security at the sametime yeah so I'll just you knowemphasize that what's happening is thatyou have these application componentsand those components are associated backto github through change requests orissue number and that's associated backto your commit and your source so we'reusing those web hooks to to completethat picture because we have what wewould call the back stream informationand github has the front streaminformation and we're pulling thattogether through those web hooks yeahand we for those unfamiliar with gettingI'll just add like 12 15 seconds on thisfor those unfamiliar with git we are notlike git itself is not like a time-basedor a file-basedversion control system it all goes backto what we call the Shaw string so everyevery commit essentially is encoded intoa nonlinear string and that's how we'reproviding all that traceability and allthat feedback back to the gift serverfrom to play oh great thanks we've beengetting a lot of questions there'sapparently been some issues with viewingthe slides you know understand all theslides will be available on DevOps commyou know sometime after the webinarwithin 24 hours so you'll be able to geteverything if you missed everything I'mgonna I'm gonna take a shot hey this isTracy what platforms are supported wellboth github and deploy have our platformagnostic so if you wanted to support Imean in terms of doing deploymentsbecause there's no agent required we candeploy to just about any environmentincluding heaven forbid yes themainframe iSeries and like I saidearlier even a evena Cisco request router if you needed toand on the github site its agnostic totwo platform so you can these are what Iwould consider true enterprise toolsthat they're not built for a particulara particular tool they are built for theenterprise and what the enterprise mightrun into in terms of platforms and anddifferent languages and environmentsthat they're working in yeah we forgethave itself we we tend to we have aVerity we have an opinion on howsoftware should be should be done interms of workflow you know we talkedabout get flow and github flow butultimately it's up to the enterpriseorganization to take that opinion andsee if it you know gels with how they'recurrently doing work and if it doesn'tget up itself as flexible enough to meetany sort of workflow requirement and nowI'm really taking off on that question alittle bit do you integrate with aLatvian JIRA and confluence absolutely ahundred percent uh-huh I knew the answerbut I want to be clear for yeah neitherside caresso again those tools keep in mindcontinuous integration tools likeJenkins and bamboo they themselves don'tdo anything but they orchestrate sothey're not they don't do compiles andthey don't do deployments and they don'tdo version control and they don't dotesting but they are a a central pointof control to run a workflow that makeall all of those tools yeah and there isoftentimes a confusion about deploy havecompeting with Jenkins and I want tokill that immediately because Jenkins isnot ever going to want to try to managea application package it's going to callother tools to do that and what mostpeople do is they write their owndeployment process and then you hearwell Jenkins is doing my deploymentswell not really some unsung hero whowrote that script is actually doing yourdeployments so who so yes these toolsfit within any of your CI CD processesfrom from the beginning to the end ofwhat you saw today you could have thatdriven by any any of the CI tools yepand then I willthey from the github site github andJIRA is probably the most commonintegration that I see outside of githuband chickens right there are support forsmart commits you can do transitions youcan do time-based tracking and it's allbuilt on the commit mapping that you'llset up on the JIRA side and that pluginsavailable in the marketplace it has fullsupport for github and github Enterpriseand then there is a confluence plug-inas well so if you're already invested inthe Atlassian ecosystem a bit hopefullyyou're not using the bucket that's okayif you are then there is support forthat as well so yep okay Chris I haveone for you what should differencebetween github and bitbucketoh that's a great question so so it'sactually uh that's a good question howdo I want to take that cuz I've got like12 different answers right so do we havethree hours because I can certainly talkor get a little time picky right I thinkI want to elevate the conversation alittle bit so in terms of what we thinkabout in terms of source code managementgithub in the book and are very similarright so bitbucket is a source codemanagement utility that was originallywritten on mercurialwhen it was - but now it's get basedwhen it's now known as bit bucket but Ithink you know in terms of where you seethe core differentiator is when you lookat that bucket in terms of its UI andits UX and I highly encourage you totake a look at this if you've never seenit beforewe always want you to check out ourcompetitors because we're usually alittle bit betterAtlassian tends to take the biggerproject focus right they want to geteverybody involved in the process andthey've really designed their UX withbit bucket around sort of the projectmanager level so if you look at how younavigate and how your pull requestslooking github it's really designed forthe project manager to have visibilityinto that process if you look at githubwe take a developer first best-of-breedapproach that is not necessarilydesigned around one ecosystem or oneplatform and is really centered on thedeveloper experience there's somethinginternally that we talked about one ofour design philosophies when it comes toactually developing our platform is thisidea around developer happiness or whatwe call like what we like to calldeveloper love as well and I know thatsounda little hippie a little bit but it'sreally about knowing that developerswork really well when they have toolsthat really that kind of get out oftheir way right developers when they'reusing github don't really have to thinkabout the tool it's just somethingthat's there and there are all theselittle things that sort of add up thatbuild efficiency one of the most commoncome what some of the most commonfeedback that I get from developers onbitbucket is that it looks like JIRA andit feels like JIRA and it's used likeJIRAthere are complex permissioning modelsthe server's themselves are not veryperformance and even some of the some ofthe feedback that I received from mycustomers when they worked if thatLaskin is that they feel Atlassian isjust not investing a whole lot into theplatform it bitbucket being an SCM toolthat they have but their big investmentis in you know more what they considerenterprise-grade tools like JIRA andconfluence so github is our product it'swhat we go to market with and we put ahundred percent of our effort into it sothat's sort of my take on it okay I'dlike to keep going there's some greatquestions here how do you handledeployment failures I'll take that oneso deployment failures are a bummer theyhappen much of the reasons why theyhappen is it because they're this theirscripts back there that are it's doingwork and it's hard to see what occurredso in deploy hub you have some optionsyou can continue moving forward which issort of a habit that we've gotten intoin the continuous integration world oryou can jump forward or back so you cando an immediate rollback should you needto even if that means you have to bringin environment variables and databaseupdates and you can or you can jump itforward so you can apply a fix and thenjump it forward now keep in mind thatthe difference between when you have anautomation tool and a scriptedenvironment is that there's somevisibility into the process and you cansee what's changed between those twothose two deploymentsso if you are trying to sort out whyyour deployment failed you can quicklylook to see what was changed from thelast time and you know probably that'swhat caused the problem so you canactually apply the fix and then movethat forward because now once you'veapplied the fix you have a new versionand you push that new version forward oryou can just do a rollback either eitherway is available and let and I reallywant to emphasize because we have thatback in version control engine that thatVerte that treats the entire applicationpackage like code and it packageseverything it versions the entirepackage knowing where everything thatoccurred to that package it makes itsuper easy to make a fix or to rollbackyep and then from our side from the SCMsite it starts and it starts with branchprotections right so essentially whenwe're opening up pull requests we needto be by default you know a hundred someof the time I always recommend that youstart protecting master your masterbranch as a branch that should not haveforced pushing and then doubling down onthat with things like acquired statusesand branch commissioning that not onlycontrol who can merge to a bridge butalso if your deployment fails open matecan send a signal back to github thatsays hey this failedperhaps we should block this pullrequest from being merged back intomaster until we figure out what'shappening right yeah okay let's into ouron deployment let me take off withanother question how does kubernetes fitinto your deployment process I love thatquestion because the more we get intothese containers and micro serviceenvironments the more important it'sgoing to be to start automating the theapplication package management sokubernetes is treated just like anythingelse so we treat containers in the sameway as we treat any endpoint keep inmind we don't have to have an agent outthere so that an agent isn't isn'trequired to be on your container priorto doing a deployment the other thingthat we are that we do is because wehave that back in version control piecewe can determine where a where versionsof of components are installed in whatcontainers so the the farther down theroad you go into the kubernetes worldand youstart using microservices you're gonnayou're gonna explode your number ofendpoints literally it's going toexplode and keeping track of who'sactually running one of those a aparticular microservice who's actuallyusing it if you have people connectingto it all of that information is goingto begin becoming more and moreimportant and in our future roadmapwe're going to start building out thosekinds of features because we alreadyknow what component is going to beinstalled on what micro service and whatwe should be able to do as well is toprovide to you if anybody's using thatmicro service so the kubernetesenvironment is is going to be extremelyimportant as we move forward and wealready do support the containers wejust joined the cloud native computingfoundation so that we have a can havecloser conversations with the kubernetesfolks and we will be looking atintegrating into helm so helm is akubernetes point-a to point-b adeployment solution and it usessomething called charts and what we willbe able to do is potentially generatethose charts with our applicationpackaging so that you have all of thatinformation ready to be pushed out byhelm so we're very excited aboutkubernetes we currently supportcontainers and we're going to bebuilding more features around managementof micro services from who's using whatyep and then I would say two add-onsthat because like Tracey said it's alljust being treated as code essentiallyyou can take two strategies around thesort of composition of the deployment ofthose orchestrators right you can themost common way and probably the mostuseful way is you treat those youbasically have those those compositionfiles those orchestration files livewithin your project so if you have arepository many times you'll have eitherlike a dot compose folder or githubfolder that takes all of those likeinfrastructure and composition specificfiles and you put it in its own isolatedenvironment or less commonly but alsoequally useful is having a separateproject that controls all thatorchestration and then using a web hookto sort of manage all of that flow aswell it's just depending on how you wantthe most common I see though andespecially if you want to get into sortof a microservices first approach iskeeping him at the repository level yeahthat's great let's take it to a littlesomething here for the company had aquestion regarding my Kershaw how welldoes this solution work with MicrosoftMVC serverswhat kind of server I'm sorry MBC Ohlike it like a model view controllerlike that like that yeah 100our partnership with Microsoft is onlystrengthening day by day so not only canyou sort of deploy any sort of MVCframework application I mean that's whatRuby on Rails is these work veryseamlessly I think you know Microsoftespecially with our relationship of themas its evolved they are getting more andmore focused on not only the open sourcebut on the modern platform as well sowe've had a chance to talk extensivelywith Microsoft and some of the stuffthat they're working on that you'll seelater probably in this coming year andthe next I think is going to be veryexciting and it's only going to tightenthat integration in terms of supportingthe entire Microsoft platform they'veput a lot of money and investment intoAzure and I think you'll see a lot ofthat but if you're using other likeon-prem tools like I is to deploy yourdotnet applications today there's 100%support for that yeah I know that's onboth sides it's on the deploy web siteas well deploy fully supports theWindows environment yeah that's great Igot a few moredo you support Haskell and CI fornixprojects casco audio so house Colby I'mgonna assume it's we're referring toHaskell is sort of the functionalprogramming language that's the only oneI'm aware ofthat's the one I'm aware of as well soyeah I didn't hear the CI part of thatquestion but I'll take it well justsaying do you support Haskell ti4NICs projects and IX I mean it's likestart next yeah absolutely that'sprobably where it gets sort of gottastart it got its start was in a you knowwhen Linus wrote it it wasor a tool geared and optimized for atthat time for the next community rightso yeah 100 percent Manchus and that'sreally I mean I think we've covered allthe questions except for a couple maybeif I'd ask your question I feel wasanswered by seeing another question I'dlike to thank everybody for coming thankTracy and Chris and if you want to learnmore about this go to open makesoftware.com Tracy do you have anyclosing comments I no I don't think so Ijust want to thank Chris and github fordoing this webinar with us it's beengreat to work with the team all rightwell I want to thank everybody forputting up with our little technicaldifficulties throughout this webinar butI see most of you stayed on so we reallyappreciate itand thank you for attending anotherwebinar and have a good rest of your dayor evening thank you everyone thank youvery much thank you
Increase the velocity of your software releases by using continuous deployment driven by continuous delivery pipeline. After all, the goal of agile is to get code updates into the hands of your users fast and on a high frequency basis. This means installing all the way to production, not just staged for productio.
This webinar will show you an approach to achieving full continuous deployment using GitHub and DeployHub. You will learn how to declare your Application Package from your GitHub repository, manage approvals and deliver updates to environments across the CD pipeline from development through production.
GitHub and DeployHub work together to provide a complete DevOps process that results in a repeatable, consistent software releases process with a full continuous feedback loop.