Welcome!

@DevOpsSummit Authors: Destiny Bertucci, Pat Romanski, Yeshim Deniz, Dalibor Siroky, Liz McMillan

Related Topics: @DevOpsSummit, Java IoT, Linux Containers, Containers Expo Blog, FinTech Journal

@DevOpsSummit: Blog Post

Our Favorite Continuous Delivery Tools By @TrevParsons | @DevOpsSummit [#DevOps]

Identifying and tracking issues as easily as possible

We're working hard in the Logentries towers to integrate our continuous delivery tools, so we can identify and track issues as easily as possible.

This saves us time that we can spend on important things like adding new features (or playing pool!). We use a lot of tools to manage our development cycle, and we've made them interact too.

We use JIRA (by Atlassian) to plan our work, Gitlab to manage our code, and Jenkins for our continuous integration.

Does Mr Jenkins Approve?

Merge requests (a.k.a. a pull request in github) aren't accepted in Logentries until Mr Jenkins is happy with it.

Mr Jenkins is listening, and whenever a new merge request is submitted, he'll go through it with a fine-tooth comb. If he's not happy, he'll reject it.

People don't like Mr Jenkins, he's pedantic.

Jenkins

Not only does he perform all of our tests (which the developer will have run before submitting a merge request, but you never know...), he also performs style checks and static analysis depending on the language:

Once he's done with his tests, Mr. Jenkins will vote on the merge request:

continuous delivery tools Jenkins message

Another failed build sir. Shall I prepare afternoon tea?

Implementation
This integration is actually very simple to implement thanks to a great Jenkins plugin: theGitlab Merge Request Builder Plugin. Once you create Mr. Jenkins' account on your gitlab site and install the plugin, you can have automatic builds running in 5 minutes.

Why You Should Bother
If you run Jenkins builds against code before it gets merged into a central branch, it can be fixed before it gets accepted!

You have to work on Stories

JiraGitlab

<->

We don't think we're unique in planning our work.

We hope we're not unique in planning our work...

We use JIRA to write stories which our developers work on, along with the occasional bug, and we've integrated our JIRA stories into Gitlab.

Gitlab can be customised to perform pre-receive checks on any commits pushed to the server.

We've written a Ruby script that checks every commit pushed to our gitlab server, and confirms the commit message mentions a JIRA issue that's in progress or blocked.

If no issue is mentioned, the push is rejected. Ouch.

If an issue is mentioned, the script goes ahead and comments on the mentioned JIRA issue to say that a commit has been made.

cd message in Gitlab

Mr Jenkins always cleans up after himself, as any good butler should.

  • Now we can track all the work that's been done on a story in JIRA.
  • Now we can see the JIRA issue that each commit relates to in Gitlab.

Awesome.

Implementation
Jira has a well-documented API which is pleasant to use.

You need to update your pre-receive hook file in:

${Git installation directory}/gitlab-shell/hooks/

Then, check if the commit message mentions a jira issue

$oldrev = ARGV[1]$newrev = ARGV[2]
revision_list = IO.popen(%W(git rev-list ^#{$oldrev} #{$newrev})).read
revision_list.split("\n").each do |rev|commit_msg = IO.popen(%W(git log -format=%B -n 1 #{rev})).readissues = commit_msg.scan(/(jira[- ]?\d+)/i)if issues.empty?puts "No issue mentioned"exit 1endend

Once you've found issue IDs, check if the issues are open using the JIRA api, and then post a comment. These steps are long, but not complicated.

our favorite continuous delivery tools

An Easy Shortcut for Lazy Developer
It can be a bit of a pain remembering the exact code of your issue (and typing it in every time), so our developers just put the JIRA issue ID in the branch name and use a  handy script we found here to automatically put the branch name in each commit message.

BRANCH_NAME=$(git symbolic-ref -short HEAD)if [ -n "$BRANCH_NAME" ] && [ "$BRANCH_NAME" != "master" ]; thensed -i.bak -e "1s/$/ [$BRANCH_NAME]/" $1fi

Why You Should Bother
Having your git push rejected seems like a huge irritation, but most people are used to a little rejection(#risqué joke), and after a couple of failures, you'll remember to mention the right ID.

This results in a huge amount of time saved for planners, because they now know exactly what's being done on that. We also have a great, interlocked, history between our revision control system and our planning system.

All Over the Shop
All of this data is a pain to manage and compare when it's spread across so many products.

Happily enough, we have just the ticket to fix that... There'll be another blog post soon on how we've integrated our CD tooling into Logentries and how we're using it.

More Stories By Trevor Parsons

Trevor Parsons is Chief Scientist and Co-founder of Logentries. Trevor has over 10 years experience in enterprise software and, in particular, has specialized in developing enterprise monitoring and performance tools for distributed systems. He is also a research fellow at the Performance Engineering Lab Research Group and was formerly a Scientist at the IBM Center for Advanced Studies. Trevor holds a PhD from University College Dublin, Ireland.

@DevOpsSummit Stories
ChatOps is an emerging topic that has led to the wide availability of integrations between group chat and various other tools/platforms. Currently, HipChat is an extremely powerful collaboration platform due to the various ChatOps integrations that are available. However, DevOps automation can involve orchestration and complex workflows. In his session at @DevOpsSummit at 20th Cloud Expo, Himanshu Chhetri, CTO at Addteq, will cover practical examples and use cases such as self-provisioning infrastructure/applications, self-remediation workflows, integrating monitoring and complimenting integrations between Atlassian tools and other top tools in the industry.
A strange thing is happening along the way to the Internet of Things, namely far too many devices to work with and manage. It has become clear that we'll need much higher efficiency user experiences that can allow us to more easily and scalably work with the thousands of devices that will soon be in each of our lives. Enter the conversational interface revolution, combining bots we can literally talk with, gesture to, and even direct with our thoughts, with embedded artificial intelligence, which can process our conversational commands and orchestrate the outcomes we request across our personal and professional realm of connected devices.
The need for greater agility and scalability necessitated the digital transformation in the form of following equation: monolithic to microservices to serverless architecture (FaaS). To keep up with the cut-throat competition, the organisations need to update their technology stack to make software development their differentiating factor. Thus microservices architecture emerged as a potential method to provide development teams with greater flexibility and other advantages, such as the ability to deliver applications at warp speed using infrastructure as a service (IaaS) and platform as a service (PaaS) environments.
The use of containers by developers -- and now increasingly IT operators -- has grown from infatuation to deep and abiding love. But as with any long-term affair, the honeymoon soon leads to needing to live well together ... and maybe even getting some relationship help along the way. And so it goes with container orchestration and automation solutions, which are rapidly emerging as the means to maintain the bliss between rapid container adoption and broad container use among multiple cloud hosts. This BriefingsDirect cloud services maturity discussion focuses on new ways to gain container orchestration, to better use serverless computing models, and employ inclusive management to keep the container love alive.
While some developers care passionately about how data centers and clouds are architected, for most, it is only the end result that matters. To the majority of companies, technology exists to solve a business problem, and only delivers value when it is solving that problem. 2017 brings the mainstream adoption of containers for production workloads. In his session at 21st Cloud Expo, Ben McCormack, VP of Operations at Evernote, discussed how data centers of the future will be managed, how the public cloud best suits your organization, and what the future holds for operations and infrastructure engineers in a post-container world. Is a serverless world inevitable?