Amadeus Contribution to the Jenkins Literate Plugin and the Plugin's Value

This is one in a series of blog posts in which various CloudBees technical experts have summarized presentations from the Jenkins User Conferences (JUC). This post is written by Valentina Armenise, solutions architect, CloudBees, about a presentation called " Vincent Latombe presenting his talk at JUC Berlin.
Click here to watch the video.
And click here to see the slides .

In particular, Amadeus invested resources in order to enhance the plugin usage experience by introducing the use of YAML, a descriptive language which leaves less space to errors compared to the traditional MARKDOWN -too open.

How do we see the Literate plugin today?

With the introduction of CI, there are conversations going on about what is the best approach in merging and pulling changes to repositories.

Some people support the “feature branching” approach, where each new feature is a new branch and is committed to the mainline only when ready to be released in order to provide isolation among branches and stability of the trunk.

Although this approach is criticized by many who think that it is too risky to commit the whole new feature at once, it could be the best approach when the new feature is completely isolated from the rest (a completely new module) or in open source projects where a new feature is developed without deadlines and, thus, can take quite a while to be completed.

The Literate plugin works really well with the feature branching approach described above, since it would be possible to define different build steps for each branch and, thus, for each feature.

Also, this approach gets along really well with the concept of continuous delivery, where the main idea is that the trunk has to be continuously shippable into production.

How does it integrate with CD tools?

Today, we’re moving from implementing CI to CD: Jenkins is not a tool for developers only anymore but it’s now capturing the interest of Dev-Ops.

By using plugins to implement deployment pipelines (ie. Build Pipeline plugin, Build Flow plugin, Promotion plugin), Jenkins is able to handle all the phases of the software lifecycle .

The definition of environments and agents to build and deploy to is provided with integration to Puppet and Chef. These tools can be used to describe the configuration of the environment and apply the changes on the target machines before deployment.

At the same time, virtualization technologies that allow you to create software containers, such as Docker, are getting more and more popular.

How the literate builds could take part in the CD process?

As said before, one of the things that the Literate plugin simplifies is the definition of multiple environments and of build steps by the use of a single file: the build definition will be stored in the same SCM as the job that is being built.

This means that the Literate plugin gets along really well with the infrastructure as code approach and tools like Docker or Puppet where all the necessary files are stored in the SCM. Docker, in particular, could be a good candidate to work with this plugin, since a Docker image is completely described by a single file (the Dockerfile) and it’s totally self-contained in the SCM.

What's next?

Amadeus is looking for adding new features for the plugin in the near feature:

• Integration with GitHub, Bitbucket and stash pull request support

• Integration with isolation features (i.e. sandbox commands within the container)

Do you want to know more?

• Read about the story of the Literate Build plugin for Jenkins

• Check out the source code

• Refer to the Jenkins Wiki

_Valentina Armenise
Solutions Architect, CloudBees

_Follow Valentina on Twitter .__