Skip to main content Skip to Footer

BLOG


March 03, 2016
Open-sourcing the Accenture DevOps Platform – What is it? Why are we doing it?
By: Martin Croker

Last month, we open-sourced the Accenture DevOps Platform (ADOP) that had proven to be a great catalyst for our own DevOps transformation.

The open source platform can be found here: https://github.com/Accenture/adop-docker-compose

There are a number of reasons behind our decision to contribute ADOP to the OSS community. First and foremost, we feel strongly that it is our responsibility to not just consume, but also to contribute to OSS. It’s also something that clients increasingly want—open standards and avoiding lock-in—along with the other benefits of open source software.

Things are emerging in this space incredibly rapidly. Prior to open-sourcing, we spent the last few weeks porting ADOP from cloud-formation orchestration, to Docker-compose. I make no claims of completeness: this platform is still in its early days, there is a lot left in the platform still to mature and develop. We will continue to evolve the platform as we increase usage within our client engagements.

So what is it?

Functionally, ADOP is a framework that glues together a suite of open source development tools and provides a really quick way of mobilizing software development projects in a consistent way, using a standard set of tools and processes (for example, Continuous Delivery). The framework can be configured for use for a particular technology using a ‘cartridge’.

These videos might give a better idea:

  • My demonstration a slightly earlier version of the stack at Jenkins user conference

Technically, ADOP is a set of Docker-composed templates which provision a suite of DevOps tools. Cartridges are imported into the platform using Jenkins jobs embedded within the base Jenkins component.

What problem does it solve?

The DevOps team at Accenture support a large number of diverse engagements, for typically large enterprise clients. Our goal is that a majority of our projects use a development process and pipeline that look something like this:

Cloud-based hosting and access to application services through Accenture Cloud Platform.

To do this well requires projects to both set up tooling and adopt appropriate working practices. If engagements can be encouraged to use DevOps from the outset, it’s far easier than trying to retrospectively apply these practices. This is where the DevOps platform gives us an edge—it not only swiftly stands up a project development environment which is already configured to use recommended practices with low-cost, rapid mobilization but also helps start the engagement on the right track to a DevOps-enabled delivery.

Actually for Accenture, the objective is deeper than that. We want to be able to spin up a project development environment quickly; and also make it reflect our corporate (and now community) body of knowledge on how to best deliver a particular technology. We have a large number of engagements active at any one point, and we want to be able to bring the right assets to each engagement.

DevOps Platform

This is where cartridges come in; the idea being that a cartridge contains a reference application for a particular technology along with appropriate configuration for the chosen tools. The vision is that an ADOP cartridge may contain not just DevOps assets, but also those from other capabilities and also from industry segments (a great example is Accenture Video Solutions).

Cartridges are currently a concept at Minimum Viable Product; and can contain git repositories and Jenkins configuration. The vision is that we would extend this to the full product set.

The architecture is based on three (perhaps three and a half layers).

Cartridges
“I don’t want to use component xxxx”

This is pretty normal for us, many clients have a preference for the toolset they use.

ADOP is something the Accenture DevOps team uses as a start-point. Where other tools preferences exist, we adapt the stack as needed—either by using a sub-set of the images or using just the cartridge configuration, or perhaps just using the concepts.

What’s next?

Some of the things on our to-do list include:

  • The DevOps platform was originally created to underpin the labs of a two-day DevOps training course. I make no promises, but I would also like to open-source the labs, and as much of the course material as we can. This year we are on track to train 4,000 practitioners and architects through this course, so it’s certainly something we see value in.

  • The initial release of ADOP contains just the one cartridge. More than anything else this reflects how new the cartridge concept is to us. We intend to extend this collection over time.

  • There’s some overlap between ADOP and Fabric8, we’d like to close this gap with RedHat.

  • We plan to evolve the coverage and architecture for the cartridges adding support for the remaining components (ELK, Jira, Sonar, …).We recognize that what we have is a bit of a MVP; and perhaps we can create something really extensible.

  • The Jenkins configuration pattern will be updated to support workflow (now pipelines).

  • And, we would like to migrate any of the Jenkins components to be a nice clean plug-in; currently this is a bit bespoke.

Popular Tags

    Archive