The Future of the Software Development Lifecycle (SDLC)

Jack (product designer) and Alex (VP of Product) demonstrate the future of the software development lifecycle.

A Transcript of the video is available below

DROdio: Hi guys its DROdio with Armory and I am here with Alex out VP product and I am here with Jack our product designer, they've got something pretty cool to show you and so I'll let them take it away.

Alex: So we're working on this feature to be able to visualize concept of lead time and lead time is typically the time it takes for an idea to return into a value for a company that's creating some type of a [inaudible 00:23] service and what we've done is we've broken up lead time into mini components and we believe that these components exist in every engineering organization. So it starts product Ideation and the product ideation typically happens in some companies and style sheets, google sheets, products like prod pads.

Jack: It could be aha.

Alex: It could be aha, so product ideation then goes through design phase and then there is some type of a design mark on being produced to socialize the customers, these things could be happening in products like envision, after that what's happening is the ideas turn into Jira tickets and these Jira tickets start getting [inaudible 01:14] on, eventually some code gets produced. That code in GitHub or your source code depository of choice. What’s happening after that is your getting with code review cycle and there is time lapse in there and we're starting to look at different parts of a software delivery life cycle or different components of lead time and the way we want to think about it is different jobs, its jobs to be done and they are jobs that are automated or there's some tooling that's used for these jobs and there is a time between the jobs, this is typically handoffs or somebody runs to talk to somebody and then the next job gets initiated. So I want to think about this as time to do something. So what happens next is your code ends up in your source code depository and it will be reviewed by a peer and eventually merged and what happens after that and I guess lets zoom in a little back.

Jack: VCS is version control system that could be GitHub in which case the code review usually happens when you create a PR poll request that's about it.

Alex: So when a poll request is created, somebody has to go review the code and then ultimately merge it. Once you merge the code a build gets initiated and that kicks off your continuous integration and continuous integration there is a variety of tools in that process. They all assemble in different ways and they all take different times to execute. There could also be menial stamps in some companies to that and so continuous integration kicks in and there is a number of build in steps in there. What happens after all of your testing has passed typically something like Spinnaker gets involved and Spinnaker essentially triggers a set of work flows and steps called stages that your artifact which is your package software goes through and what we notice because we're really kind of handling currently this part, the deployment piece we notice that there is a lot of inefficiencies within that work flow and Spinnaker you can create menial stages or menial approval stages which is for many companies it’s a way to create more safety to their deployments and it usually means that during that menial stage there is some menial steps that are happening like menial QA or somebody has to go talk to somebody or some script has to be run and that takes time and so we're kind of moving past this now. So let’s say we've gone through all these different jobs and now you’re at a stage where your software has deployed to your production environment which could be in any cloud provider and with Armory Spinnaker you can actually have multiple targets. Whether it’s your GCP, its Kubernetes, it's Amazon ECS all of those are targets and this is where your software eventually ends up and today it's not over yet because what happens next is once you deployed your software to your production environment, your now most likely which happens for many style companies you encounter issues in production and a lot of times it's because you know you’re not perfect, there are bugs, Spinnaker missed integration testing or your unit tests. So a bug ends up being in production which causes an inability problem, so at that stage you are now kind of getting into we call time to resolution stage which is still is adding to your total lead time to deliver value because now you engineer who was writing code is troubleshooting an issue of production in the middle of the night, most likely they're not going to show up to work the next day and so all of that is captured by time to resolution and so at some point the engineer got woken up by something like pager duty to a point they've actually resolved the issue and they have pushed an update, that's the time that they spent working on it. After that what's happening is your feature is in production and you may be doing some AB testing with a service like [inaudible 05:39] to farther validate your features and the last mile here is that your feature start to have value in meaning a sales person in sales force checks an option to turn a lead into an opportunity and into a sale and that completes your cycle of generating value but most of the time the developer has after they spent or not spent time to resolution after they deploy their service to a production environment and then the features is in the customers hands they return back to Jira to pick up the next station. So this is a summary of kind of the value stream, what we call the value stream map that we're creating that enables us to visualize the lead time and then take different jobs and optimize them.

DROdio: So Alex one thing that I just want to say and I want to ask is we always say that Armory is just not solving a deployment problem, its solving an innovation problem, there is a lot of inefficiencies in this pipeline and specifically I've heard you say that you'd like to get this whole process down to one second outside of the coding from all the inefficiencies that takes minutes or hours or days today, companies don’t even know where the inefficiencies are, you’d like to get that done to one second and I think what your also showing. So if you can talk about this your imagining this is actually Armory platform is showing a visual representation of this for each specific company.

Alex: Exactly that's the feature we're building right now, the cool thing about Armory platform is that we already connect into what we call systems of record. Developer systems of record, business systems of records. So what we have connections to today is we have connections to Jira. So we already integrate with Jira because Armory deployment platform is able to pull status from Jira and also update all the tickets, they are currently associated with the particular built. A lot of companies tag their releases with Jira ticket numbers and so because we already have the build artifact we were able to back track and figure out all of the Jira tickets that are associated with the particular release and at that point as your software moves to different stages we were able to update those Jira tickets and also pull more information out of them. So we have connection to Jira, we have connection to obviously all of your built systems because we are taking the artifacts from artifact depository store all the way to let’s say Amazon or cloud environment and so we have all that information as well and we already integrate with services like Data dog and New Relic and Elastic search. Services that companies use to figure out the root cause of a lot of these problems. So a cross this whole software delivery life cycle and this value stream we already have connections to a lot of these places and what we know today there is no single way of visualizing for a lot of organizations. Companies don’t really know where the bottlenecks are, they don’t really know what is preventing them from shipping software fast, they don’t know what affects their velocity week to week or month to month and so this is our way, not only for us to figure out where to optimize across our whole customer base, it’s also for customers to visualize how they're making progress with their continuous delivery efforts. A lot of companies are driving continuous delivery and it's not very clear how to actually visualize their being successful and so this tends to create a visualization for ourselves across many customers so we can figure out how to prioritize and also give this experience to our customers as well.

DROdio: And Jack as our product designer I'm sure you will make this experience amazing.

Jack: Yeah, so we are actually are kind of mapping out right now, looking at points along this time line where we can get involved. So the ways that we're getting involved right now include the Jira integrations, we've got a little Jira icon that starts right when you finish figuring out what you want to build and starting to actually code it out. So Jira issue, you tag that, that goes into kind of Armory universe and then we're going to take from that universe all the points at which there are right now inefficiencies we're going to try to pull those points in your universe close together. So we want to take the whole time to code and then getting your code review and that should be automatic right, so this slack [inaudible 09:59] that we've integrated can create notifications for the person who needs to look at the code and get it reviewed similarly the web interface offers integration with of course the Armory Spinnaker and then as you go through into deeper stages of the process we can shorten the progression between each of these spinnaker stages by including and this is even within the Armory, a notification in the armory slack [inaudible 10:27] about something happening in Amory Spinnaker and so you can really I think we basically want all the steps that don’t involve people to happen instantly and so the train just keeps running automatically.

DROdio: So one thing that I've heard you guys say was actually the product manager was a customer was the one that helped us conceptualize this, is like the most expensive thing in his company isn’t his cloud bill, it’s the unmerged PR's that all the codes have been written and is sitting on the shelf. So I see you've got a little Armory slack [inaudible 11:00] here so I imagine in an engineering channel the add Armory and Amory says to them 'hey this PR is sitting unmerged for the last forty hours or whatever,’ and then they could also access that through like the web platform interface for example is that accurate?

Alex: We're creating features in Armory platform to essentially optimize each part of this value stream for different companies and we already have a number of interactions as you mentioned we're looking at the time it takes to merge a full request and we're trying to shrink that and we found out by creating a digest identifications in slack and presenting them every morning to the team in their channel of what outstanding PR are and how long these PR's are sitting around creates lessons to the time those PR’s are sitting around, so that's just one example. We also found ways to reduce time to resolution by shortcutting the time it takes to roll back to the previous release. A lot of times we are rolling a software out, you know its problem, it kicks off a chain of events by different people in their organization or in engineering team that go into tools like Data dog and New Relic and look at various alerts and start figuring out what to do but a lot of times they really need to do is to roll back to the previous healthy release. Amory and Spinnaker have great functionality tool back, what we’ve don’t is farther optimize the time to resolution by bringing that action ability straight into slack. So normally we are able to detect by integrating with something like Data dog that your software is unhealthy, we are actually able to give you an action straight out of slack to just roll back to the previous release so your team has in their disposal, they don’t need to go to many other places and try to figure out how to do that. That's the type of reducing the time functionality of brining in.

DROdio: Another great example here is like automated canary deployments, like limit that blast radius so that if that new version is not healthy it’s not your entire customer base that’s being impacted and you have less stress in work everyone at 2 AM trying to fix it and just move forward

Alex: We’re trying to cover kind of both sides before your software rolls out. So by adding automated canary analysis and automated canary deployments but then if your software does get into production and it still has an issue then we're shortcutting that time to resolution as well. So the overall goal is to shrink this as much as possible because our theory is that it will increase velocity, you know shorter lead time equals high velocity, equals more revenue for that business.

Jack: And maybe it’s worth noting as sort of a high level insight overall, this is all the infrastructure as code, method of building software which can save a lot of headaches that we're not mentioning like sever drift and all the problems with mutable deployment stuff, that's kind of the overall direction that everyone's moving and we basically are sprinkling experiences throughout that process whether it is a digest of the open poll request instead of the engineering channel getting blasted with notifications constantly or it’s a pipeline template that you could use while your deploying to help with the configuration so you only have to do it once and not every time you want to deploy. Those are the types of things that we're trying to integrate and create and it might be in Jira, it might be in Slack, we want to essentially be platform agnostic and just make Armory like your personal assistant as you call software.

DROdio: Cool.

Alex: I think one other point to bring up here is we're trying to go to where developers are, so we're trying to integrate into the developer environment as close as possible and so Slack was one of those examples where developers pretty spent a lot of time in Slack and so we're bringing that type of functionality into slack directly and avoiding any other interfaces like the traditional web interfaces. We're also know developers spend a lot of time on ID so we're thinking about how to integrate this closer to the ID environments because that where developers spend most time and we want them to be productive, we want them to just focus on the coding part. Once they get their Jira we want them to code, we want them to create their template pipelines within that ID and we also want them to be able to interact with their deployments through the ID. Same thing with slack, so right now we're kind of building for all three but we're seeing a lot of conversion stores, I just want for all this to come to my environment, I don’t want to go anywhere, so.

DROdio: Well gentlemen, thanks for building the future it looks amazing and if you’re watching this video and your curious about this, if you would like to give this a try, some of this already exist in production, very stable today, some of it is coming and so we have a need analysis that will ask you to fill out and we can help you discern whether you should be an early adopter of what you’re seeing here and what’s coming or if you need something just really stable in production, we have components of this already installed with many customers already. So thanks for the time