A myriad of point-tools, frameworks and infrastructures are involved in your software delivery process – from development, through build, testing, deployment, all the way to a Production Release.
While many of these tools are free/open source, the operational and technology overhead of orchestrating the hand-offs from one tool to the next in the process – are not without cost.
To improve developer productivity and resource utilization – and to enable enterprise-scale, cross-project visibility and shorter time to market – organizations are working to automate and orchestrate the entire tool chain across the end-to-end delivery pipeline.
“Automate All the Things” is a key tenant to any DevOps or Continuous Delivery initiative.
This workshop will use a real case study and a live demo to show how you can use a free DevOps Release Automation tool – ElectricFlow – to orchestrate your entire software delivery pipeline. In this demo, we will create a fully-automated release pipeline deploying a Cloud Java application, tying-in common tools that you likely use in your process from CI build to Release: including Git, Jenkins, Selenium, Chef, Docker, and more.
Learn how to:
• Seamlessly orchestrate third-party tools to automate your entire process- from start to finish
• Get visibility into your end-to-end application release pipeline
• Deploy any application to any environment using any tool-set – for free
We’re going to talk about how to automate all the things – and how to take advantage of all of the free tools you are already using and orchestrate them in your end-to end release pipeline.
My name is Avan Mathur, I am a product manager at Electric Cloud – and until recently I worked on site with a number of our users helping them achieve their DevOps goals on ElectricFlow.
I will start with some slides outlining the scenarios that we see out there, and then will move into a demo with an example use case!
We will take a look at what we see sofware delivery pipelines often looking like. But to start – what does your software delivery pipeline look like?
Is it a straight shot – from check in to SCM all the way to your production environment? If so, you probably look like that happy face giving us the thumbs up.
In reality – we have seen that most people live here. The delivery pipeline is not one straight shot. There is a lot of complexity and legacy processes, numerous tools, manual steps and approvals required and decision points that all need to be completed - leaving us looking more like the second overwhelmed face there. Going through all of the complex steps slows down the cycle time and can increase possibility of errors or failures in your deployments
This challenge is magnified when you see the number of tools that are being used across your processes. Here you can see a number of tools that are being used in a software delivery process. It is possible to orchestrate and use all of these tools in your process, and many smaller teams do this.
But what happens when this we take a broader view at more than one team? Each team is using their own set of tools. Here we are taking a look at 4 different teams – one of them may be more on the dev side, another on the QA, while the other on the Ops side. They are all focused on delivering great software, but are looking at it from a different perspective – using the tools they think are best to solve the problem.
If you look at the market in general – there are so many tools available to solve each set of problems – and most companies will have at least two of each kind, we see this very often. And this list of tools is growing with new innovation every day to solve these specific pain points in the end to end software delivery process.
Having these options is great – and different people will gravitate towards different technologies, but how do all of these fit into our end to end pipelines?
Where do those tools fit into your commit pipeline. Lets take a look at a sample pipeline and where we can see all of the points where different tools can come into the picture.
Starting on the left we have our commit pipeline. With every step we will be integrating with tools – SCM and CI systems to get started, and a repository system to publish artifacts for testing . In Test there needs to be an automated deployment of that artifact to the test system – whether it is in OpenStack vm that needs to be provisioned or a Docker container. The tests themselves can be run through a tool and on success - if things look good we would deprovision any cloud environments to prevent zombie VMs sitting out there and then you can have the optional manual approval before moving on to the next stage.
Now on the right side we have our sample release pipeline. Again, with every stage there are points of integration with different tools – We start with the integration stage where we start retrieve that same artifact from the repository and run through similar steps provisioning the enviornment – configuring it with something like Chef or Puppet.. Then automating the deployment and running tests.
It is important to have fidelity of process, environment and artifact as you move from integration to your production. As you get to production, you want to have confidence in the process, environment configuration and the artifact that being deployed before pulling that final trigger pushing to production. Knowing that the exact same process configuration etc was used in earlier stages brings that confidence.
Many of our users then have multiple commit pipelines – each pipeline could introduce different tools and technologies – where some are using bare metal, others cloud environments, and others using Docker containers.
Some of the users we work with have a handful to tools, but many have large numbers – where we can see 60+ tools being used across this end to end pipeline. Without a single way to orchestrate this all, they can end up like that overwhelmed emoji.
This brings the question – how many tools does your team use? What does your stack look like? How do you – or how would you – bring those all together into your delivery pipeline?
It can be a challenge to have the sprawl of tools across the organization, but it is also not easy, or really feasible to come in and try to standardize across all of your different teams, with mandates to use only a certain set of tools across your pipeline. What you really want is to orchestrate all of the different tools that are being used across the organization throughout your end to end delivery pipeline in a single place. tHis allows for easy migration and onboarding for new teams into your release pipeline system, without asking them to reinvent the wheel.
We are doing just this at one of our customers now who is a large bank – they are in the process of onboarding 1000s of applications onto ElectricFlow pipeline – that we have designed and build in a generic, parameterized fashion. They are able to come in and plug in their existing tools with each process, but use the same underlying model and framework across the organization.
That is what our product – ElectricFlow, allows you to do. You can orchestrate your end to end pipelines using shared models for your applications, processes environments and pipelines – and for overall releases that can be comprised of multiple applications being deployed to different environments with one push a of a button.
We give you shared control and visibility across the tools – you can dig into each approval for auditability – and views across the environments to see what is deployed where at any given time – there is the visibility for troubleshooting deployment and configuration issues., we commonly see issues tied to that lack of fidelity across your environments.
The product is enterprise grade. It will work well for a small devops initiative, but is also ready for when you need to scale it up and across a larger organization. Providing the flexiblity, security and high availabilty that is required at that scale.
On top of the automation platform we have a Web UI which I will show you in the demo– as well as commandline interface, Domain Specific Language and REST API that allows you to integrate into the platform from other tools.
The platform then has different built in solutions for automating the different pieces of your software delivery cycle. Starting with build/test and a scalable CI - to Deploy where we use that model based application and environment to abstract out complexities and allow you to deploy your application in the same way to any environment, be it cloud, container or something else.
Finally we have release – whether with one or many applications – you can coordinate your pipelines into a single release pipeline – so you don’t have to worry about clashing with something that is already in production, you can coordinate and schedule out releases at the whateve cadence your team requires.
We have those use cases out of the box – but you can really automate any use case on top of our very powerful and flexible platform.