GitHub Universe 2018 - Scaling your business, 10 Nov 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Innersource and the power of automation at Eli Lilly - GitHub Universe 2018

Description

Presented by Nick Liffen, (Eli Lilly & Company).

Learn how engineering teams at Eli Lilly shifted from locked down repositories to open collaboration and automated service offerings, along with a few tips and tricks for working better together. You’ll also hear how automation supported teams as they adopted GitHub Business Cloud and made it simple for engineers across the organization to configure repositories, enforce security policies, and more.

About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.

For more information on GitHub Universe, check the website:
https://githubuniverse.com

A

♪ (music) ♪.

A

All right,, I think, we're about ready to get started.

A

So, good afternoon!: how is everyone this fine wednesday afternoon?.

A

We can do a lot better than that!.

A

Let me ask one more time.: how is everyone this fine wednesday afternoon?

A

(audience responds) there we go, there, we go! well, thank you, everyone, for coming..

A

Before I get started,, I just want to make a shout-out to the two other talks going on at the same time. airbnb were doing a great talk into microservices and github, with social issues and code.

A

So, really appreciate you joining us., as you can see by the screen,. Today's topics are going to be focusing on lilly's journey into innersourcing,.

A

And also the power of automation and how we now drive an automation-first strategy.

A

Now,, the one main thing that I want you as the audience to get out of today.

A

Is how innersourcing has changed reusability and software development at eli lilly.

A

I'll going to give you some tips and tricks to hopefully for you to go back and apply into your companies.

A

So,, a really quick introduction to myself.

A

My name is nick liffen, and I work for a company called eli lilly.

A

quick hands, up, people who know who eli lilly are.

A

Okay,, that's quite a few people.

A

for people that don't,, I will explain more in a second.

A

and within eli lilly,. I work within the global information services. Team.

A

Now, we specialize within the emerging technologies group,.

A

Focused on standing up and maturing modern technologies across our enterprise.

A

Now, I joined lilly about two years ago, now.

A

I joined as a product owner, so for our modern paas and saas solutions like github,, heroku, and contentful,.

A

I would say, over the last six or seven months,.

A

We've been focused on innersourcing., I've been trying to advocate and drive an innersourcing strategy for lilly.

A

A quick fun fact. I love to use icons in presentations..

A

I think you're going to see that come true. Here.

A

Now, for the people that didn't put their hands up.

A

For knowing who lilly were-- we're a company, that's been around for roughly 140 years, now.

A

With that 140 years-strong heritage,, we have 140 years of technology, legacy.

A

We probably have every technology, that's ever been created under the sun.

A

Somewhere being used at lilly., our headquarters are in indianapolis, indiana.

A

Have we got anyone? That's traveled from indiana today?.

A

Okay, a few at the back and a few at the front,, it's good to see.

A

We have roughly, as of march, 38,000 employees--,.

A

18,000 in the us and 20,000 ous.

A

But the main thing that I want you to take away from this slide here is we're a global pharmaceutical company,.

A

Highly regulated, and we operate in roughly 120 different countries.

A

So,, that's the background into lilly and who we are.

A

Focusing on the agenda for today,.

A

Seventy-Five percent of today's topic and conversation.

A

Is going to be focused on our innersourcing journey,.

A

Going back to where this all began in 2016.

A

To where we are now and what we want to do to move forward.

A

And 25% is going to be focused on our automation strategy.

A

And how we used to be fully manual in all of our processes and services,.

A

And how changing that to an automation-first approach.

A

Has massively helped adoption,, but also experience of our platforms and services.

A

Now, before we get into actual innersourcing,.

A

I really want to focus on the team that I work for.

A

I want to ask one: question.: does anyone know in the audience or want to shout out what cirrus is? I've tried to give a clue on the slide.

A

Does anyone want to shout out what cirrus is,, if they think they know what it is?.

A

No bites? okay. so,, my icon, games-- okay, yep.

A

Cirrus is a fast-moving and lacy cloud,.

A

And that is summarized by the dictionary..

A

This is the name our cto gave the team that I work. For.

A

The team that I work for tries to focus on mature and stand ups and embeds emerging technologies.

A

Across our whole enterprise., so we sit in the middle of that, and we try and bring new technologies along and then make them consumable to all of our business-facing. It teams.

A

Now,, as I said, earlier,, we have lots of different technologies.

A

This is a high-level landscape of some of the technologies that we have as of today,, focusing on our devops toolchain.

A

So, tools that cirrus have worked on.

A

We've stood up heroku as our platform, as a service,.

A

Github, contentful for our api for cms.

A

And over the last few, months, we've really focused on standing up an automated ci and cd,.

A

And that's, we use, is jenkins..

A

So that's given you the background into today's presentation,.

A

And that really comes into play further throughout the next few slides.

A

I now want to focus on innersourcing.

A

so,. I want to ask a quick question.

A

hands up. If you know what innersourcing is or you think you know what innersourcing is., okay. wow, good hands., keep your hands up.

A

hands up. If you are using innersourcing in your company, today.

A

Okay, good hands. leave your hands up. one further question--, if you've been doing it longer than two years.

A

Okay, is there any--, we have one,, maybe two hands..

A

So that's really good to see..

A

Innersourcing is quite a new concept,, but it has different variations of what innersourcing means.

A

And for people that didn't put their hands up,, I really want to start by saying what is innersourcing.

A

Different companies do have different opinions on what innersourcing is, and that's okay., one common thing that we see when we think about innersourcing.

A

Is people always say, "oh, innersourcing can only be used in companies, of an enterprise.

A

Innersourcing can only be used in companies that are large and have lots of silo teams.". That is not true.. Innersourcing is a culture that can be applied into teams of 10, teams of 20..

A

It's really about breaking down the barriers between any teams.

A

And as you're reading, this quote here,.

A

This is what lilly class as innersourcing,, and this is what we would class as our vision, statement.

A

Four main points that I want to point out in this slide.

A

Are open, source,, community,, collaborative engineering, and culture.

A

They are the four main drivers that lilly class as innersource,.

A

And you need to apply the innersource principles.

A

you need to have the community..

A

You have to have some sort of collaborative engineering between the silo teams.

A

but most importantly--, and I think this is the most important out of all four--.

A

It's about trying to drive that culture change in your company.

A

So,, this slide will be referenced multiple times throughout the presentation,, but this is what we are trying to achieve when we think of innersourcing.

A

Now,, I want to take us way back to a few years, ago, in 2016,.

A

And this is really where, unintentionally,.

A

Our innersourcing journey actually began.

A

so, we're obviously a large enterprise company, and we use multiple different technologies., but in 2016, cirrus stood up a platform called heroku.

A

This was our first,. I would say, in a change of tools and services that we use.

A

teams were very used to using legacy technologies.

A

And very monolithic architectures..

A

They couldn't build in a way that heroku allowed..

A

We were very focused on .net previously,.

A

And it didn't allow developers to build out and express themselves.

A

In ways that they wanted to. but then heroku came along, and teams started to shift and be like, "wow,. I can now develop my application in node, in python, in go"--.

A

It just didn't matter., and this is when the sort of buzz around internal software development.

A

Started to happen.

A

that led to really happy developer teams, because they could maybe shift away from very traditional .net coldfusion siloed ways of doing things.

A

Into a more modern concept of software development.-.

A

But one thing that they found was they actually didn't know where to start.

A

So they would go onto heroku,, create their applications,.

A

But they actually couldn't get up and running..

A

They were so used to doing things in a very monolithic way.

A

And a very traditional way., they couldn't just simply port their .net application over to heroku.

A

So when you think about building that node.js application or that python application,.

A

Teams really did struggle to get started., but it wasn't just that.. It was when they did finally get there,. Teams would be building multiple things.

A

So, a great example of this is: you would have different teams, building the exact same thing.

A

So, in heroku,, you have your pipeline,, your dev,, your stage,.

A

And your production application., every team needed some sort of authentication.

A

For the dev and the stage applications., each team would go out and build this exact same thing.

A

So,, within the first few months of rolling out heroku,, we had roughly 200 applications, each team went out and built their own authentication side of things.

A

And that's where cirrus-- so the team that we work for--.

A

Took a step back and sort of realized, "well,, there's actually great opportunity. Here.

A

All these teams are doing the exact same thing..

A

Why can't we just build it once and then offer it out for teams to consume?" and that's what we did, cirrus went out and built an npm module that just handled authentication.?

A

You would plug in your own client id and your client secret, and it would automatically authenticate for you., and we also built out a web blueprint. So teams could then get started.

A

And this really helped, because now teams had a place to start,.

A

But also it meant that teams were used to starting to consume.

A

A module that had already being built, and they wouldn't have to do it themselves. and when you start to think past this-- and we move to now early 2017.

A

When we started to see more and more of these use, cases.

A

So we had the authentication use case..

A

We saw a bunch of teams that were interacting with our api gateway, and it was taking them ages to actually do it, because, again,. When you think about modern programming, concepts,.

A

Something that we hadn't done too much. so,. What we did was we went away and built these three modules.

A

Now,, you can see some facts on the screen. Now.

A

We went out and got some data by different teams on how long, roughly, it took them to go and do these things.

A

So,, if five project teams went out and built these modules.

A

And it took three days, as you can see, there's a massive time reduction-- if cirrus went out,, built them once, and just offered them for everyone to use.

A

And that's what we went and did.. We started to see some really nice success here, and we actually weren't the only teams going to do this.

A

Teams started to realize, "well,. I can actually just go and build my own npm modules.".

A

Other teams had their own internal use, cases,.

A

So, rather than cirrus going out and building this reusable asset,.

A

They would go and do the same thing.

A

all they would do,, they would go and build it and we were using gemfury at the time for hosting our npm packages.

A

They would publish it to their own gemfury repository,.

A

And then they can start consuming it. so,, we weren't the only ones. when you think about the slide that I was telling you previously around community,.

A

We had other people going out and building these modules,.

A

And that really helped with some quick wins.

A

So we had just stood up our platform, and it meant that we were saving application teams' time.

A

Going out and doing the software development.

A

that led to the business being happy, and that led to an increased adoption of our platform.

A

so, from the cirrus perspective,, we were really happy..

A

We had teams coming in, consuming our platforms, and we were getting some good feedback.

A

secondly, when you think about the security and quality point of things,.

A

Working in an obviously highly-regulated company, it is really important to consider these things..

A

All we did is we had that central place of security and quality.

A

That if one of the dependencies had a vulnerability,.

A

We would go and update it, and then other teams could just consume it. Straightaway.

A

So it isn't just about saving time., it's also the quality and the security point of things as well.

A

Now, at this point of time,, I want to take a step back.

A

We're in 2017, and at this point we actually genuinely thought.

A

That we were doing this innersourcing thing., we were like, "wow,. We actually have teams going and consuming the modules that we've built..

A

We actually have teams going and building their own modules.".

A

But is that really innersourcing?.

A

Now, one thing that we actually realized was because we had no catalog,, because we had no discovery,.

A

Teams were going out and building the exact same things that we had already built..

A

We had built an authentication module-- so had another team,, because they actually didn't know that we had already built it..

A

Let's say that we went out and built a module that helped integrate with postgres databases,.

A

But another team didn't know that we'd built that so they would go and build it. so, did we really have the collaborative engineering?.

A

I suppose we sort of had the community,, but the collaborative engineering we've been able to develop between the teams was not there.

A

And then you have to think about it from a developer, perspective.

A

So a developer would come and try and consume a module from cirrus,.

A

And then they would try and consume this module from another team.

A

And it would be such different processes..

A

Let's say they wanted to log an issue,. Let's say they wanted to log a pull request,. The readme formats were different., so developers were getting incredibly frustrated because they were coming to us, saying, "I. Don't want to use any of your modules.

A

Because other teams have gone out and built something different to what you have,, and it's just so difficult at the enterprise level.

A

For this to be a consumable process." and that really hit home for us..

A

For the teams that had embarked on this reusability journey,, I call it now,.

A

That really took us a step back.

A

When you think about this quote, I showed earlier--.

A

We sort of had open source,, we were opening up our repositories for people to use, and we were opening up to consume from.

A

But did we have the community?

A

sort of--? We did have teams coming in and building.

A

So, yes,, we did have some community,, but it was not where we wanted it to be.

A

We 100% did not have the collaborative engineering.

A

Teams were going out and still building in silos.

A

This is not really what we wanted: innersource to be,.

A

And we definitely did not have that culture.

A

So,, taking a step back around what innersourcing is.

A

And what you're, seeing on your screen,.

A

Innersourcing is not just about going out and building code,.

A

Because that's what we'd done. and we realized that we had focused so much on going out and building the code that we hadn't even taken a step back and thought about what is the end-to-end process.

A

so, that takes me to here..

A

This was me in late 2017.

A

When I realized, we need to change this.

A

Something isn't quite right: here.

A

I really thought that going out and building these modules-- and yes, it was saving teams time,, but we have so many barriers that we still need to knock down,.

A

And we aren't doing really what innersourcing is meant to try and achieve.

A

so,? What should we do? Differently?

A

now,? This is where me and a few other people took a step back.

A

As advocates of innersourcing and say, "what, are we missing?" if you haven't paid attention to anything,?

A

This is the slide that I would recommend that you pay attention. To.

A

This is what lilly call our seven pillars of innersourcing.

A

This was us taking a step back..

A

This was us realizing that it is not all about code,.

A

It is not all about building these assets.

A

there's so much more than that..

A

This is what we now 100% try and look to.

A

Whenever we build something new., we try and emphasize these pillars anywhere. We go.

A

So, internally, we try and say that we need to try and reach these,.

A

But also, externally, innersourcing is such a new concept.

A

And teams really struggle to get up and running., but with these seven pillars, we've made such a change,.

A

And I'll explain why, in the upcoming slides.

A

So,, let's start on the left-hand side, where it's build.

A

Yes,, you always have to go and build that reusable asset--.

A

That is important. at the end of the day,. You are trying to save teams, time.

A

But what happens if there's no tests?, what happens if you haven't tested it?? Why is a developer going to consume that package, that microservice,.

A

If it hasn't been tested? what about validation?, it's really important, as a consumer of your module,.

A

To know that it's going to do what it's meant to do.

A

I think if anyone in the audience uses npm and you try and download something,.

A

It's really annoying when you download it,, try and consume it,, and it doesn't do what it's meant to do.

A

so,, it's really important to validate and give that piece of mind to the consumer that it is going to do what you're meant to do.

A

storage. previously,, as the teams were storing these packages,, these services.

A

In all different gemfury repositories,, we needed that single point where teams could come and deploy to.

A

So teams didn't have to go to many different places.

A

Now, the next three, in my eyes, are the most important.

A

It's really about discoverability and consumerability.

A

I want to be able to go somewhere and say, "well,. I need this.. I need some sort of ad group authorization..

A

Has it already been built?? Is there a catalog out there where I can see everything? That's already been built?" and then, when I do find something,, how do I consume that module in the same way that I consume all the other ones?

A

me, as a developer,? I don't want to have to try and consume something in four different ways, just because four different teams have four different processes.

A

But it then leads on to the support..

A

Let's say someone has a question.: let's say that someone has a bug or wants to log a feature.

A

We then started to put a process around how we,.

A

As custodians of the modules, need to respond.

A

So if someone logs a bug,, do we try and respond in six hours?.

A

Do we have a process around that?? It's really important that if someone does log a pull request,, if someone does log an issue,, don't just leave it. There. have issue templates,, pull request, templates, code, owners--.

A

All of these things are github saying to us,.

A

"We need to focus more on trying to support the people.

A

That are consuming the packages that we've built." and then, finally,. We need to measure success..

A

I've actually got something in a few slides that tries to quantify if lilly's innersourcing journey.

A

Has been a success or not. so,: that is what we overall call our seven pillars of innersourcing.

A

So,, where are we now??

A

A developer can come and read all the documentation.

A

Which is, in itself, innersourced in github.

A

I think it's really important that you document your end-to-end process, so a developer can come and say, "okay,. This is a process that I need to follow to consume this module." "this is a process that I need to follow to go and build a module.".

A

And let's say they go there and they can't find a module. That's already been built.

A

What they can do is they can automatically request a github repo to get started,.

A

And they can automatically create a jenkins job.

A

now,. This is fully automated.. All the developer needs to do is go to our service catalog, request, it,.

A

And it actually pre-creates the jenkins job, and we have enterprised jenkins pipelines that do specific things.

A

So, in our case,, if someone wants to go and build an npm module,.

A

We have a jenkins pipeline that does the tests,. Does the deployments.

A

They don't need to worry about any of that.. The developers shouldn't be in a place where they have to worry about going out and building the deployment or manually. Deploying it. jenkins is automating that end-to-end process,, so the developers just focus on going into that repo,.

A

Building the code, building the module that they want to build.

A

And once they've built it, jenkins will do all of the testing for them in our enterprise way,. So we know that anything deployed to our package manager.

A

Has been through, tests, has got the validation, because it's all included in that jenkins pipeline.

A

When they're ready,, they then deploy it to jfrog artifactory.

A

so,. We shifted away from gemfury, and we now move to artifactory, where we have a single repository per package. Type,.

A

Whether it's python,, whether it's [nuget],, whether it's npm., we have one repository per language,.

A

So there's no more of this going to six different repositories.

A

And that's helped massively because we now have a script that takes everything out of that repository.

A

And publishes it to our developer, .lilly portal.

A

So, in lilly,, we have a developer's site where it shows all of the getting started guides..

A

It also shows a catalog for all of the modules,, all of the services that have been prebuilt, and there it takes you directly to artifactory..

A

It takes you directly to github..

A

It shows you how many downloads it has..

A

It then starts to benchmark that module..

A

It then benchmarks over time how many downloads it has from artifactory., but it also shows how many times it's been found in our lilly.org,.

A

In the package.json dependencies.

A

So we can now say that our package has been downloaded 1,000 times,.

A

And also it has been found in github, 14 times.

A

And then all we do is we have a github team that has all of our lilly employees in.

A

We just add that team to the repos straight away,.

A

And you now have our end-to-end process of how teams go and build modules.

A

Now, I've mentioned npm a lot..

A

That is where we've started to focus this initial journey.

A

But we're also trying to shift to python.

A

it isn't just about building that single language,.

A

It's about trying to meet the developer needs for multiple languages.

A

now,. Let's go back.. We now have started to build a process around things.

A

so,. Going back to that mission. Statement..

A

We still have the open source,. We are still opening up libraries,.

A

And we finally have a place where we have community..

A

We have community contributing to documentation.

A

so,, we're now happy with where we are from a community perspective.

A

And now we have a process where we have pull request templates,, we have contributing files,. We have issue templates.

A

We actually now have multiple packages where teams are contributing across silos.

A

A great example is we built a module to interact with our lilly s3 service.

A

Other teams have then come in and contributed to help improve it,.

A

And we have four different teams who have contributed to that one package.

A

Who work in completely different aspects of the organization.

A

Now,, we're aren't there yet on culture..

A

Now we have the end-to-end process laid out,.

A

We need to take it to the next level and try and promote that culture,.

A

Try and promote the education of innersourcing and the benefits.

A

And the way we're going to do, that is by showing statistics like this.

A

So far, we have built 45, reusable npm, modules.

A

Now,, in the time that we have moved to artifactory--, that was march 2018--, we have had roughly 135,000 downloads coming from that artifactory repository.

A

That could be a developer downloading into their local machine,.

A

That could be heroku downloading from heroku, that could be lambda., but we've had 135,000 downloads.

A

But, most importantly, is what you're seeing on that next graph.

A

What we do is we crawl github,.

A

And we look across all of the package.json dependencies.

A

For how many of the packages are included, there.

A

So, in march 2018, ever since way back in 2016 to 2018,.

A

We had 200 reusable assets that had been actually used.

A

Across all of the 45,, they were being used, 200 times.

A

If you now look at where we are now,, we have over 700 of these modules being consumed in our lilly.org.

A

And then the downloads speaks for itself.

A

so, when you think about results,. Ever since we've shifted to building in that process and trying to build in that consistency,. The experience and consumption of innersourcing has definitely increased.

A

Now,, I wouldn't want to finish without giving some lessons. Learned.

A

I would say: definitely don't do what we've done.

A

Definitely do not focus on going out there and building the code.

A

It's so easy to go out and build these assets straight. Away--.

A

Whether it's a python package,, whether it's a node package,, whether it's a microservice., you can go and out and build it and say, "hey, everyone--, you can consume this.".

A

But it is not where you want to start.

A

that does provide the quick wins,, but over the long period, we have had to go back and spend so much time re-engineering our end-to-end process.

A

now,. What I would recommend are three things.

A

Focus on consistency. obviously, for the people that work within a large enterprise,.

A

You do have different teams. >from, a developer perspective,. You do want that consumerability to be the same.

A

Whether they're consuming a package from one team or another team,.

A

You really want to be as consistent as you can.

A

document that end-to-end process., when you think about the seven pillars that I showed you earlier,.

A

You may take away and say, "well,, four or five of these are useful;.

A

Two of them aren't." take a step back and try and realize what is the process that you need in your company to be successful.

A

And then finally,, some of the feedback from our consumers of innersourcing.

A

Ever since we've automated that end-to-end delivery.

A

Of deploying packages to artifactory--, so they don't need to do any of that. their consumption and the feedback has been fantastic.

A

So, from our perspective,, they are the three things that we would advise. Anyone.

A

Who is new on the innersourcing journey to start on. now, that focuses on our innersourcing journey,.

A

Talking about when we started in 2016 to where we are now in 2018.,.

A

I now want to shift gears for the last 25% of this presentation.

A

And talk a little bit about our automation journey and how that has helped drive adoption.

A

Now, again, you'll hear a theme here., let's get back to 2016.. This is where all of these things started to become quite big..

A

Let's say that a developer wanted access to get help.

A

Let's say that a developer wanted to create a github team.

A

Or create a github repository., they had to go to servicenow.

A

so,. We didn't allow developers to directly create repos in github.

A

We didn't allow them to create teams or just directly get access.

A

And a few people may be asking, "well,. Why is that?".

A

I've put a few examples on the screen: here.

A

One,, we rely quite heavily on naming conventions.

A

For our metrics and our benchmarking.

A

so,, allowing teams just to go into github and say, "hey,, pretty please,.

A

Please adhere to these naming conventions"-- that was not going to work. but also,. When you think about people who are new to github, who were coming over from tfs,, they didn't really know where to start.

A

so, if they could have someone doing it for them and creating that repo--.

A

That helped them massively., but it also allowed us to help drive some best practice..

A

It allowed us to lock down the master branch for them,, so at least when they went in they had something to start with that wasn't going to straightaway not set them up for success.

A

So,, that was the process in 2016,, and this is really what it looked. Like.

A

I think for any developer in the room or any consumer. That's in the room that has been through this process,.

A

You know the pain. so,, a developer would go to servicenow, and they would say, "I need a repository," or "I need to get access.".

A

They would make the servicenow request, and they would wait.

A

They would wait for an approval because it needed to have an approval, process. and they would go and check the servicenow request, and it would take a day, and they would get really frustrated..

A

But then they'd go back, and they'd see that it had been approved,.

A

And they were like, "finally,, it's going to be here.", but then it had to be triaged to our support team..

A

The support team would then go and fulfill the request.

A

that took a few days. and for something that actually only needed to take like five minutes,.

A

It took five days. now that was not setting them up for success,.

A

But it was not setting github up for success.

A

teams would much rather go and use legacy tools and legacy services.

A

If it meant they didn't have to wait.

A

so, the adoption of github,, even though everyone was so excited,.

A

It really actually didn't help.

A

so,. We decided to take a step back and help drive an automation-first strategy.

A

While still having the security in place.

A

We decided to automate all of our requests coming out of servicenow.

A

So,, a developer would still go to servicenow., they would still go in, and whether it's requesting a repository, requesting a team,.

A

They would still go to servicenow,, make the request,, but they wouldn't have to wait.. We automated the approval process and we automated the fulfillment.

A

So, yes, teams here may be sitting there. Going,.

A

"Well, we as well have to abstract that [away].", just because you're being told by your security and quality teams that you need to have that audit history or you need to have some mechanism in front of your services,, like github,.

A

Don't let that be a barrier.

A

we went and automated all of our catalog items,.

A

And ever since then, the adoption and the experience has massively increased.

A

You can see some stats on this screen around what it used to be.

A

So, before we had all of the automation,.

A

It roughly took 5 days,, 20 hours and 58 minutes.

A

For someone to do something in our github catalog item.

A

But ever since we automated that, that went down to roughly 45 minutes.

A

now,, you may be asking--. Why is it taking 45 minutes?.

A

We do batch repository creation,, so a user can come in and say, "I need 30 repos.".

A

I don't even want to go to servicenow every time I create one repository,.

A

So we allow people to come in and create a batch of repositories.

A

So they can add a batch of 30 and not go to servicenow.

A

For weeks or months, or, however long they now need their next batch of repositories.

A

And to show some facts and the data there, it's a few months out of date,, but we had 2,397 repo requests.

A

In our new automated catalog., we have over 700 member requests.

A

and right now,. We have increased to 4,200 github repos.

A

We're on nearly 1,500 active developers who are in our organization.

A

And the total time saved--, you can see there--, I'm not even going to try and say that number., but that is the total time saved. If you compare how long it was taking in our manual service requests,.

A

To where we are at now, with our automated one.

A

So, that helps drive some of the value and help in driving automation-first strategy.

A

But that isn't where we've stopped.

A

we've then taken it forward and helped drive a more automation-first.

A

Across everything that we do. so,, what we actually do is we do automatically delete repos over time.

A

And I know that's scary for some teams, but as you allow automation,, you allow teams to then create as many repos as they want.

A

And never go and delete them., and I don't know if anyone else faces the pain,. But we were at a massive number of repos.

A

The teams just weren't going and deleting them.

A

so, over time,. We have special requirements that then say,.

A

"If, it hasn't met the lifetime of [inaudible], an issue,.

A

A pull request, a commit,, a push--. Any activity has happened on that repo,.

A

We go and zip up the contents of that repo, move it to an s3 bucket, and we then archive that repository.".

A

So we are able to automatically remove the junkyard effect.

A

That automation can cause., we have an automated script for removing users.

A

So,, when you think about github's license-- of course,, you obviously pay per user-- cost is obviously important.

A

so,. We have a script when a user has last made a commit,.

A

As you've done something in github,, we go and remove them from the organization., and you can see the two others there, we're removing the collaborators and deleting teams., and this has all helped drive less of a junkyard that we have.

A

Now, one thing that we're happy to do as lilly is try and open source these..

A

These are tools that we use in lilly..

A

I was really inspired by the talk this morning at the keynote.

A

So,, if anyone's interested in any of these tools or scripts,.

A

I'd love to chat to you afterwards about what we can do to collaborate on them.

A

so, as we're coming up to time--. We have five minutes left--.

A

I did want to say thank you.. Thank you for taking the time.. I really appreciate you coming to the session..

A

I know there were two other fantastic sessions..

A

You can email, me,, linkedin me, or you can go to my github profile., but thank you ever so much for your time and have a fantastic rest of the afternoon.

A

thank you.. (Applause) ♪, (music) ♪.