The business case for using Jenkins X

The business case for using Jenkins X

Far from being a replacement to the widely loved Jenkins, Jenkins X builds on the classic with best of breed open source tools.

But it’s a little more exciting than that.

In the words of James Strachan, Distinguished Engineer at CloudBees, Jenkins X is a big deal because “as a developer, you can type one command jx create or jx import and get your source code, git repository and application created, automatically built and deployed to Kubernetes on each Pull Request or git push with full CI/CD complete with Environments and Promotion via GitOps!”

And breath…

Essentially, it makes smart decisions for you, its cloud native and its geared specifically for Kubernetes. Handy features when businesses are looking for ways to adopt cloud technologies, reduce manual tasks, and focus on driving value to compete at pace. But it hasn’t always been so plain sailing.

It’s fair to say that Jenkins X addressed some of the challenges its predecessor Jenkins has traditionally faced. A continuous integration tool long before Kubernetes entered the DevOps scene and distributed systems running on cloud native platforms, the current shift to cloud native and containers began to pose Jenkins management-specific challenges for enterprises. Users were also finding the use of Jenkins as a stand-along open source tool difficult at times.

The changing landscape meant that when Jenkins X was released back in early 2018, it found a way to both improve and automate continuous delivery pipelines to Kubernetes and cloud-native environments – something that hadn’t been possible with Jenkins.

But the dream doesn’t stop there. Ultimately, CloudBees is evolving its tools in keeping with the evolution of the modern DevOps pipeline. And it seems that the hope is that Jenkins X will eventually blend with the classic Jenkins to create one experience that facilitates serverless and automated pipelines, on-premise deployments and modern cloud applications. CloudBees would also like to see Jenkins X help Jenkins to become more cloud native in the hope it benefits the wider Jenkins community in addition to Jenkins X.

The question is, with such a shift still taking place, why would an enterprise go to the trouble of using Jenkins X? We think we’ve found a few answers…

It’s popular, and it works.

Ultimately, Jenkins X is a CI/CD solution for modern cloud application on Kubernetes – but with a few bells and whistles up his finely ironed suit jacket. Not only does the tool provide pipeline automation, it has built-in GitOps and preview environments to enable greater collaboration between teams and the acceleration of software delivery at scale.

Feedback on commits, issues and pull requests are also automated, with feedback delivered as code that is ready to be previewed and promoted to environments – or if pull requests are generated automatically, to upgrade versions. By spinning up preview environments ahead of merges to the master, Jenkins X has answered the much-requested ability to gain faster feedback.

In fact, it’s been so well received, CloudBees | Jenkins X has been described as “evil in the best possible way”…

It’s user focused

Devout compliments asides, Jenkins X has been carefully considered to put the developer’s best interests front and centre.

Best described in the words of James Strachan, Jenkins X is “a project which rethinks how developers should interact with CI/CD in the cloud with a focus on making development teams productive through automation, tooling and DevOps best practices”.

Defaulting your favourite pipelines and having them fully implemented with CI and CD for projects is an equally nifty addition for the time conscious and meticulous developer.

It addresses the CI/CD challenges in a cloud native landscape

As noted by Craig Barber, Software Engineer, Google:

“Jenkins X is an industry-wide leap forward to provide developers with a cloud native CI/CD experience. As the next evolution in the Jenkins space, Jenkins X redefines how CI/CD workloads run.”

And it was a much-needed leap too! Traditional CI/CD systems such as Jenkins weren’t designed for cloud-native environments, and as such, these tools have either had to evolve or introduce new family members to the tool stack.

In the case of CloudBees, Jenkins X was created to meet the demands Kubernetes placed on engineers wanting to deploy and test easily during deployment workflows. Born as a cloud-native tool, Jenkins X has simplified the integration of tools in the Kubernetes ecosystem for an opinionated open source solution fit for the modern enterprise.

CloudBees | Jenkins recently bagged HSBC’s vote, and a rather sizeable cheque…

It’s certainly not risk-free, but when an established enterprise such as HSBC is prepared to make a capital investment of $10million into an open-source software company, it’s difficult not to take notice.

HSBC’s CTO of Shared Services Dinesh Keswani says the investment was motivated by a desire to better serve their customers. They are also one of the enterprises driving change:

“The DevOps market is growing fast, as organisations like us drive automation, intelligence and security into the way we deliver software. CloudBees is already a strategic business partner of HSBC; we are excited by our investment and by the opportunity to be part of the story of continuous delivery.”

But HSBC aren’t alone. An estimated 15+ million software developers currently use Jenkins to automate their software delivery pipelines. Of this 15+ million, 46 belong to the Fortune 100 and three sit within the Fortune 10 – all using various tools within the CloudBees Suite to transform their businesses for the unremitting economy. And this number is likely to grow as CloudBees continue to conquer the CI/CD landscape.

Sacha Labourey, CEO and co-founder of CloudBees says that the funding will be used to continue introducing new innovation to the DevOps market through modernising its software delivery suite, growing its strategic partnerships and driving growth in its global business – as we’ve already seen through its recent acquisition of Electric Cloud and Rollout. Whilst not devoted solely to the evolution of Jenkins X, a few things suggest that Jenkins X will undoubtably gain its fair share of the pie:

Described in its infancy early last year, we look forward to seeing the progress Jenkins X has made at this years’ DevOps World | Jenkins World. Not only will some of the team be heading out to sunny San Francisco, we are proud to be heading out as CloudBees | Jenkins training partner of the year and training sponsors for the show.

DevOps World | Jenkins World

Hands-on with Jenkins X Jenkins X Panda

If you’ve been inspired to give Jenkins X a try for yourself, join us on July 24th for this month’s DevOps Playground, led by CloudBees’ very own Gareth Evans. If you’ve missed tickets on Meetup/Eventbrite, look out for the video recording post-Playground!

This Playground we’ll be learning how to be up and running with Jenkins X in no time, using the CLI to create new applications and promote them to staging and production environments. We will also be demonstrating our use of GitOps and ChatOps to interact with Jenkins X and will show how to utilise Preview Environments to get faster feedback to the developer.

Key Takeaways:

  • Use the JX cli to create a Jenkins X cluster on GKE
  • Create an application based on a set of templates
  • Push the application to a staging environment using GitOps
  • Change the application, interact with the PR using ChatOps
  • Learn how Preview Environments can speed up developer feedback
  • As much pizza as you fancy

As you can see, this is a Playground not to be missed! Join the waiting list here.

 

Eloisa ToveeThe business case for using Jenkins X
read more
CloudBees & Electric Cloud: the holy grail for CI/CD software?

CloudBees & Electric Cloud: the holy grail for CI/CD software?

As a specialist DevOps consultancy, ECS Digital often finds itself at the forefront of new and emerging technologies. We work with clients that aim to solve ever more complex problems and have established a history of working with industry-leading software vendors in response to the tools required to tackle these problems head-on. This has enabled ECS Digital to become intrinsically linked to the ever-evolving nature of the business software world.

What we’ve come to realise is that there is a natural lifecycle to the software vendors we work with. Some will grow quickly, establishing themselves as leaders in their market, and will eventually go public in an IPO. Some will fail, falling away as victims of the marketplace. And some will be acquired by another software vendor to be included in a wider portfolio of products. This is a common trend, as we have seen with GitHub joining Microsoft and Red Hat becoming part of IBM, both in multi-billion-dollar deals.

And this trend continues, with CloudBees and their recent acquisition of Electric Cloud.

Electric Cloud is the second business to be acquired by CloudBees – Codeship, a continuous integration and continuous delivery firm, being the first in 2018. These deals pair nicely with two of the end-of-life cycles outlined earlier. They also affirm CloudBees’ overall strategy of acquiring smaller, specialist software companies as a way of bringing onboard expertise missing from their current offerings.

In the words of Andy Cureton, Managing Director and Founder of ECS Digital:

“Combining CloudBees and Electric Cloud gives the combined entity the capability breadth to compete against the AWS CI/CD stack and the Microsoft CI/CD stack prevalent on Azure. Combining the feature depth of multiple tools in a seamless capability that is platform agnostic also gives a powerful alternative to those with a brown field site, as well as addressing concerns around vendor lock in (particularly on Cloud)”.

Phil Drouet, Head of Channel at ECS Digital, agreed with Andy, adding that today’s software landscape enables users to “build their own pipeline and pick their own tools. Whilst it may seem that choosing one ‘continuous delivery powerhouse’ limits your choice, this is offset by integrated systems and better experience. At the end of the day, you don’t want every development team to have their own tools. I have no doubt that enterprises will see this as a good thing, a credible alternative to having to buy everything from different places”.

Is CloudBees the holy grail for CI/CD software?

Electric Cloud is a known brand in its own right, with Gartner positioning them as a leader in its Magic Quadrant for Application Release Orchestration just last year. By acquiring Electric Cloud, CloudBees have strategically strengthened their position in the CI and CD space, as well as allowing them to enter the end-to-end solution market. This will help protect them in a marketplace that is increasingly offering these solutions when migrating to the Cloud.

Not only are they home to the enterprise version of Jenkins, they now have a compelling brand story within the CI/CD and release automation arena. What’s more, these products can now be combined into a single suite, offering the holy grail of product portfolios, without the complexity. In the words of Sacha Labourey, the CEO and co-founder of CloudBees:

“As of today, we provide customers with best-of-breed CI/CD software from a single vendor, establishing CloudBees as a continuous delivery powerhouse. By combining the strength of CloudBees, Electric Cloud, Jenkins and Jenkins X, CloudBees offers the best CI/CD solution for any application, from classic to Kubernetes, on-premise to Cloud, self-managed to self-service.”

The joining of CloudBees and Electric Cloud will unquestionably result in a stronger product set, and thus a stronger brand for those looking for a CI, CD and release platform partner. Electric Cloud evidently feel the same, as being a previously well-funded vendor meant that this acquisition did not come about as a result of them struggling in the marketplace. Much the opposite; “it will strengthen the market for them as a unit and give CloudBees (and now Electric Cloud) another revenue stream” (Phil Drouet).

And it benefits users too, as noted by Christina Noren, Chief Product Officer, CloudBees:

“Having the Electric Cloud offerings under the CloudBees umbrella gives companies a greater ability to manage the delivery of value to customers.

Having CI and CD solutions under one banner may mean customers come to rely on CloudBees. But where monopolistic powerhouses have spelt doom for innovation in other markets, in this case, Andy Cureton sees this as “giving back control” to the customer. It’s a holistic offer that means customers lessen the risk presented by multiple vendors and unintegrated systems.

What this acquisition means for partners

Being the Service Delivery Partner of the year for CloudBees, and with a partnership stretching back many years, we will inevitably see a shift in what we will need to provide following the integration of Electric Cloud.

Part of this shift will involve witnessing new challenges emerge, especially during the ‘settling in’ period where the merging vendors decide upon strategies, personnel and technical directions. We’ll also be keeping an eye out for any innovative products born from this acquisition and look forward to introducing these offerings in future projects. Whilst nothing has been confirmed, we imagine CloudBees will begin to release more information regarding their new direction towards the end of the year, timing it nicely with their annual DevOps World | Jenkins World | CloudBees conference – this year taking place in sunny San Francisco and Lisbon, Portugal.

Despite the turbulence that may occur, working closely with partners in the DevOps software world, and having a legacy of trust and reliable support, we are best placed to deliver the same high-quality service support to software vendors at times of change. And thanks to our existing relationship with CloudBees, we are able to upskill our team at pace. We can get ready to hit the ground running as new tools and technology emerge as a result of this deal.

Not only has their recent acquisition piqued industry interest, CloudBees have reaffirmed themselves as a technology vendor to watch. Not only are they bulking up their market presence, they are also providing customers with an extensive offer in the CI/CD and Release Automation space. And since this new option will be simpler and more robust, more customers will no doubt be drawn to this valued convenience. After all, complexity is the killer of progress.

If you’re yet to reap the benefits of CloudBees and Electric Cloud for your business, talk to a member of the ECS Digital team today.

 

****

Image Credit: <a href=”https://www.freepik.com/free-photos-vectors/background”>Background vector created by creative32965 – www.freepik.com</a>

Phil DrouetCloudBees & Electric Cloud: the holy grail for CI/CD software?
read more
Behaviour Driven Development in a nutshell

Behaviour Driven Development in a nutshell

If you’re new to Behaviour Driven Development (BDD) and don’t understand the jargon surrounding it, this is the article for you. This article will explain the most fundamental concepts as well as the basic implementation of this agile methodology.

Let’s start by clearing up the misconceptions. BDD is not limited to test automation and it is not about tools. Fundamentally, BDD is actually about great communication, where an application is specified and designed by describing in detail how it should behave to an outside observer. In other words, BDD is about working in collaboration to achieve a shared level of understanding where everyone is on the same page. That’s the basic understanding you need to know. Easy enough.

So, what does this ‘great communication’ mean for software development?

Great communication means:

  • A usable product first time round, which allows you to get your product to market faster
  • A lower defect rate and higher overall quality
  • A workflow that allows for rapid change to your software
  • A very efficient and highly productive team

How is it done?

Meet our key stakeholders/teams:

Developers • Testers/QA • Project Manager/Scrum Master • Product Owners/BA

 

To illustrate what happens when you implement BDD, here are the before and after scenarios:

Before implementing BDD

Traditionally, software is designed in a waterfall approach where each stage happens in isolation and is then passed along to the next team. Think conveyor belt factory style:

  1. First the Business Analyst defines requirements
  2. Then the development team work on these requirements and sends for testing
  3. Then testing discovers lots of bugs and sends back to the development team
  4. Things are miscommunicated in transit so repeat steps 2 and 3 back and forth until you run out of time or budget
  5. Release software

The problem here is that everyone is in isolation, interpreting the requirements differently along the way. By the time code is handed in for release, resources are drained, and people are frustrated as there are issues that could have been avoided had everyone just been working together initially.

After implementing BDD

  1. Business and PO/BA have a set of requirements ready to implement
  2. BA, Developers & QA work collaboratively to refine these requirements by defining the behaviour of the software together. Thinking from the point of view of the user, they create detailed user stories. Throughout this process they address the business value of each user story and potential issues relating to QA that may crop up
  3. Each story is given an estimate of how complex it would be to implement
  4. The whole team now has a strong shared understanding of the behaviour of the software and when it will be considered complete
  5. Begin Sprint: Developers & QA then work together or in parallel to produce a product that is ready for release

 

BDD

 

This process saves time and money and is incredibly efficient. The core element of this efficiency is the team’s clear understanding of scope and what the fundamental features and behaviours required are. Because of the collaborative nature of BDD, issues are brought to light that otherwise would be an afterthought. For example, how a feature might behave differently on mobile or how a feature might deal with a large number of users. These are considerations that should be addressed from the outset.

What is the best way to implement BDD?

Just because people are in the same room or present at the same meeting doesn’t mean they will collaborate effectively. Each of the stakeholders play a crucial role and some teams/individuals may need to change their way of doing things to make sure that collaboration actually happens. The image below outlines the key deliverables for everyone involved when adopting BDD:

 

BDD

 

An example of BDD in practice

BDD is a risk-based approach to software development; it mitigates the likelihood of running into issues at crucial times. Teams at ECS Digital have been using the BDD process effectively, including  implementing a website feature for a popular media client. The client wanted to create a swipe feature where more mobile users could swipe to see different articles and move through the sections easily. Everyone was collaborating from the initial stages and the team was able to ensure high quality on the website throughout the process of implementation.

With a clear and shared definition of what the website would be like when completed, they were able to innovate further to mitigate the risk involved. They decided that during times of low traffic they would send users to the new website with the new swipe feature and get feedback. Then during risky times of high traffic users would have the usual website without the new feature. This allowed the team to ensure that when they made the feature a permanent part of the entire website they were taking as little risk as possible.

If this team was not utilising BDD techniques by defining the website’s behaviour in detail and involving each team in the development of requirements, they may have released the feature without such precautionary measures or run into many issues when approaching the release date.

If you’re interested in understanding more about BDD and delving into some of the jargon surrounding it – “gherkin syntax”, “the three amigos”, “impact mapping” & “living documentation” – read our previous article here: Behaviour Driven Development: It’s More Than Just Testing

Kouros AliabadiBehaviour Driven Development in a nutshell
read more
How to go from good to great with Jenkins CI and ECS Digital

How to go from good to great with Jenkins CI and ECS Digital

Jenkins CI is probably the most widely-used Continuous Integration platform in use today. Started in 2004 under the name Hudson, the platform quickly grew into one of the world’s most-loved Open Source build servers, and was renamed Jenkins CI after forking from the original project with Oracle. Today, Jenkins enjoys one of the most dedicated and active Open Source communities, with contributors from all around the world consistently adding new features, plugins and capabilities to an already robust software platform.

But for all the richness of features that Jenkins CI provides, many users stick to the bare minimum and don’t get as much value as they could out of their use, for example Jenkins new open source pipeline plugin. In this blog, we’ll look at the difference between good and great use of Jenkin CI, and how ECS Digital can help you get the most out of your Continuous Integration software.

Jenkins CI provides an intelligent CI platform – are you making use of it?

First off, it’s worth mentioning that not every CI pipeline needs all the bells and whistles attached – if a basic pipeline is all you need to ensure your software service is delivered on time and to your users’ expectations, you’re already making good use of your software. That being said, virtually every average CI pipeline stands to benefit from a more intelligent CI, even if it’s largely a means of shortening development windows or running more reliable tests. Many organisations use Jenkins as a glorified Cron job that runs static commands at predefined times rather than making the most of one of the thousands of potential plugins and features. The real power of Jenkins CI is its ability to act as an intelligent platform that understands how your software development journey fits together, ensures the output is of highest quality, and keeps the necessary tasks ticking over in the way that works best for your organisation.

Developers all around the world – including some members of ECS Digital – contribute plugins that make it easy to customise and optimise Jenkins CIfor particular needs. There are also a number of plugins that add cross-software support, such as the Docker/Jenkins plugins released in 2015. In this sense, Jenkins becomes much more than a CI tool – by centralising parts of the delivery and deployment pipelines, Jenkins becomes the roadmap and orchestrator for your entire software development journey.

What is the best way to become a Jenkins Jedi?

There’s only so much that you can read about getting the most out of Jenkins CI – for an in-depth understanding of the way the software works, and how to use its advanced features and plugins, it’s essential to have practical, real-world experience. There are a number of platforms for online Jenkins training, as well as some substantial forums, videos and podcasts that discuss best practices for creating Jenkins pipelines, but being walked through a practical example and having the opportunity to question one of our Certified CloudBees Jenkins Platform Engineers should you have any difficulty makes Jenkins training courses a far more beneficial option. For more about the benefits of hands-on DevOps training, read our previous blog on the subject. ECS Digital offers regular Jenkins training courses, ranging from basic introductory classes and general Jenkins best practices in our User course, to managing complex workflows and using Jenkins’ more advanced features in our Admin course. Our courses are a 50/50 split between theory and practical skills, which gives attendees a holistic understanding of how to build a good CI pipeline, and our experienced course instructors work on a one-on-one basis to ensure you get the value you need.

With over 12 years’ experience helping enterprises around the world deliver software faster and at a lower cost through the adoption of DevOps and Continuous Delivery practices, ECS Digital is the perfect DevOps training partner for anybody looking to grow their understanding of DevOps and develop their skills in a variety of software platforms. For more information, or to book a training course, view our upcoming courses by following the link below.

Image credit: tamaramccleary.com

Andy CuretonHow to go from good to great with Jenkins CI and ECS Digital
read more
DevOps: What it isn’t is just as important as what it is

DevOps: What it isn’t is just as important as what it is

Over the past few years, DevOps has been steadily gaining traction in enterprise IT for the benefit it provides in driving business forward at a faster pace. The results speak for themselves – from ‘unicorn’ companies like Etsy and Netflix, who seem to be able to achieve the impossible through DevOps, down to start-ups and Small to Medium Enterprises (SMEs) who are realising its potential as a way to eclipse their competition.

But as the hype around DevOps continues to grow unabated, many companies fall into the trap of ‘doing DevOps’ at the expense of actually implementing value-adding DevOps practices. In this blog, we’ll look at why effective DevOps adoption depends on understanding what DevOps isn’t,as well as what it is.

“Doing DevOps” isn’t the same thing as adopting DevOps practices.

In an article on DevOps.com, David Geer sums the ‘doing DevOps’ paradox as follows: “No one should be doing DevOps. It’s not an action, it’s not a title, it’s a blanket term for approaches that bridge the gap between traditional operations and development groups.” The first, and most important thing to understand about DevOps is that it isn’t, as Geer says, a title or an action. It is the combination of people, processes and tools, assembled in accordance to guiding principles and best practices that results in a more efficient delivery of better quality software. Many organisations make the principal mistake of creating a ‘DevOps team’ without considering what this truly entails. Creating a specialised DevOps team is counter-intuitive – DevOps makes organisations more efficient by breaking down the barriers that traditionally exist between dev and ops teams, and creating another silo within your organisation will only work against what you’re trying to achieve.

Automation isn’t all there is to DevOps, but it’s an important aspect.

One of the most common misconceptions about DevOps is that it’s just another word for automation. I’ve already discussed why DevOps is more than just automation in some detail in an earlier blog post, but the point is worth reiterating here. Automation constitutes a vital component of DevOps, but automating a few processes doesn’t mean you’ve achieved anything. What you have created are islands of automation where systems are loosely connected often causing further silos of expertise within the ecosystem. Automating the right processes is key to creating value for your business, and this depends on having the necessary insight into the way your business works. As Alan Sharp-Paul says in his blog on UpGuard, “A common misconception for Enterprises commencing their automation journey is that the key preparation work is choosing a tool and training their staff up. These are necessary evils, sure, but the real work is actually gathering requirements. With legacy infrastructure in play, what matters most is getting visibility of current state.

Without visibility into the current state of your business and target objectives, automating processes is akin to drawing names from a hat, at best. In other words, don’t automate what you don’t understand.

Adopting DevOps doesn’t mean downsizing or shedding staff.

DevOps doesn’t mean throwing out all your developers and operations staff and replacing them with an all-star ‘DevOps team’ that can accomplish anything in no time at all. In fact, it’s quite the opposite – DevOps is about empowering your existing staff to achieve more by working more closely together and automating the vital links between traditionally disparate departments. Creating a specialised DevOps team might seem like a great way to fast-track your organisation, but this is counter-intuitive to the benefits that DevOps provides. Ultimately, adoption of DevOps allows you to get more value from your existing workforce, not replace it with another, smaller unit.

DevOps is notoriously hard to define, and it can be even more difficult to adopt without a clear understanding of where you should be heading. ECS Digital has over 12 years’ experience helping organisations in many industries around the world realise the value of DevOps done right providing a independent and agnostic approach to what works best for your organisation. If you’d like to know more about how we could help this become a reality for your organisation, please contact us for a DevOps maturity assessment.

Image Credit: www.linkedin.com

Andy CuretonDevOps: What it isn’t is just as important as what it is
read more