ci/cd

A simple guide to provisioning Vagrant boxes with Ansible

A simple guide to provisioning Vagrant boxes with Ansible

Over the last couple of weeks, I’ve been working on some Red Hat JBoss BPM Suite workshop material. One part of the workshop is a four-hour lab that guides the attendees through the development of JBoss BPM Suite 6.x processes, rules and applications (note that this workshop is available to our customers, please contact your Red Hat account manager or local Red Hat sales representative for more information), but I’m going to be sharing part of the story with you today.

The lab-sessions require a pre-installed and pre-provisioned virtual machine, which contains all the material required to run the lab. This means that I need to create, install, provision and deploy a virtual machine that contains all the required tools and code to successfully run the lab sessions. Obviously this can done by hand, but what’s the fun in that?!

Manual work is error prone, hard to reproduce and definitely hard to version control. Hence, we want to have an automated solution in which we can (declaratively) define the layout and configuration of our virtual machine. Say hello to Vagrant and Ansible!

Continue reading “A simple guide to provisioning Vagrant boxes with Ansible”

Share

How to install and configure Jenkins to build .NET apps on Red Hat Enterprise Linux

In the process of writing my posts (#1 and #2) on .NET Core and RHEL, it was made clear to me by several friends that I had neglected to use the de facto standard for continuous integration on Linux, Jenkins. Always happy to try out new (to me) tools, I settled in for what I was assured would be a simple configuration to test out my previous work in this bastion of automation.

What is Jenkins?

The first order of business was to understand the difference between Jenkins and TeamCity, another popular CI platform. After 20 minutes of reading, I discovered the following crucial differences:

  • Jenkins has been around longer (though not always under the Jenkins moniker).
  • Jenkins is open source.
  • There are many plugins for Jenkins.

Other than these three things, any noteworthy differences I found seemed to ultimately boil down to personal preference. Even so, with my research out of the way, it was off to the races!

Continue reading “How to install and configure Jenkins to build .NET apps on Red Hat Enterprise Linux”

Share

Build your next cloud-based PaaS in under an hour

The charter of Open Innovation Labs is to help our customers accelerate application development and realize the latest advancements in software delivery, by providing skills, mentoring, and tools. Some of the challenges I frequently hear from customers are those around Platform as a Service (PaaS) environment provisioning and configuration. This article is first in the series of articles that guide you through installation configuration and usage of the Red Hat OpenShift Container Platform
(OCP) on Amazon Web Services (AWS).

This installation addresses cloud based security group creation, Amazon Route 53 based DNS, creates a server farm that survives power cycles, and configures OCP for web based authentication and persistent registry. This article and companion video (view below) eliminates the pain-points of a push button installation and validation of a four node Red Hat OCP cluster on AWS.

By the end of the tutorial, you should have a working Red Hat OCP PaaS that is ready to facilitate your team’s application development and DevOps pipeline.

Please note: The setup process uses Red Hat Ansible and an enhanced version of the openshift-ansible aws community installer.

Continue reading “Build your next cloud-based PaaS in under an hour”

Share
Install Ansible on Red Hat Enterprise Linux

Install Ansible on Red Hat Enterprise Linux

As far as automated configuration management tools go, Ansible is “the new hotness” on the market. I admit, I am pretty new to Ansible. Until recently, the majority of my configuration management experience has been rooted solely in Puppet. Tack onto that my recent foray back into the world of Red Hat and I have a lot to learn, starting with getting Ansible installed and running on RHEL. There are two ways to install Ansible—via yum, or directly from source. Yum is obviously easier. However, in the event you are working in a closed system, compiling from source may be your only option. I’ll cover both in this article.

Continue reading “Install Ansible on Red Hat Enterprise Linux”

Share

Red Hat Keynote Mobile App

This year’s middleware keynote address at Red Hat Summit talked about microservices, the power of the pipeline, and how developers and devops can work together to release code to production at a much higher rate.

The keynote also demonstrated how releases can be shipped so you can switch from the existing deployment to a new deployment (blue/green deployments), and demonstrated how to roll out a canary deployment to a subset of users to test out new features. (If the canary “dies”, roll the deployment back. If it lives, gradually ramp up the release of the deployment until all users receive the new code. )

To show all of this off, we needed to create something visual, where users could see the deployments change right in front of their eyes. That’s where the Red Hat Keynote Mobile Application came in.

Continue reading “Red Hat Keynote Mobile App”

Share

Continuous Delivery to JBoss EAP and OpenShift with the CloudBees Jenkins Platform

If you are using JBoss Enterprise Application Platform (EAP) for J2EE development, the CloudBees Jenkins Platform provides an enterprise-class toolchain for an automated CI/CD from development to production.

The CloudBees Jenkins Platform now supports integrations with both Red Hat JBoss Enterprise Application Platform (EAP) and Red Hat OpenShift across the software delivery pipeline. This enables developers to build, test and deploy applications, with Jenkins-based continuous delivery pipelines in JBoss via JBoss EAP 7 or JBoss EAP 7 on OpenShift.

The following examples are based in Jenkins Pipeline plugins, which create complex pipelines, if needed, , to model their software delivery process. If you are not familiar with with the CloudBees Jenkins Pipeline plugin you may find  these two blog posts  helpful for ramping up: Using the Pipeline Plugin to Accelerate Continuous Delivery — Part 1 and Part 2.

Let’s get started. In a typical CI/CD pipeline, your process would be similar to this one:

  • Developers commit code to the SCM, which will notify Jenkins via web-hooks.
  • Jenkins compiles the code and execute a series of test on it: static code analysis, code metrics, unit testing, etc.
  • If everything goes well, Jenkins would deploy the code to a development environment.  This step typically /may  require a manual approval depending on the use of that environment. A typical use case is having the application deployed just to be able to run further validations with tools like Selenium.
  • The steps that follow would promote the application between the various environments and to validate that the deployment was correct.

Let’s see how the build, deployment and promotion between the various environment can be done for both types of JBoss installs, to JBoss EAP7 and to JBoss EAP 7 on OpenShift,  and the differences between them.

Continue reading “Continuous Delivery to JBoss EAP and OpenShift with the CloudBees Jenkins Platform”

Share

Carving the Java EE Monolith Into Microservices: Prefer Verticals Not Layers

Following my introduction blog about why microservices should be event-driven, I’d like to take another few steps and blog about it. (Hopefully I saw you at jBCNconf and Red Hat Summit in San Francisco, where I spoke about some of these topics). Follow me on twitter @christianposta for updates on this project. In this article we discuss the first parts of carving up a monolith.

The monolith I’m exploring in depth for these articles will be from the Ticket Monster tutorial which for a long time has been the canonical example of how to build an awesome application with Java EE and Red Hat technologies. We are using Ticket Monster because it’s a well-written app that straddles the “non-trivial” and “too-complex for an example” line pretty well. It is perfect for illustrative purposes and we can point to it concretely and discuss the pros and cons of certain approaches with true example code. Please take a closer look at the domain and current architecture in light of the further discussions.

TM Architecture

Looking at the current architecture above we can see things are nicely broken out already. We have the UI components, the business services, and the long-term persistence storage nicely separated and decoupled from each other yet packaged as a single deployable (a WAR file in this case). If we examine the source code, we see the code has a similar structure. If we were to deploy this, any changes to any of the components would dictate a build, test, and release of the entire deployable. One of the prerequisites to doing microservices is autonomy of components so they can be developed, tested, deployed in isolation without disrupting the rest of the system. So what if we just carve out the different layers here and deploy those independently? Then we can achieve some of that autonomy?

Continue reading “Carving the Java EE Monolith Into Microservices: Prefer Verticals Not Layers”

Share
Push it Real Good: Continuous Delivery for the people at the push of a button and repo

Push it Real Good: Continuous Delivery for the people at the push of a button and repo

The Problem

Several months back, our emerging Developer Programs engineering team assembled during the last breaths of Brno’s Czech winter and dedicated a full day towards a deceptively complex task:

Be a user.  Assemble in groups and, using a technology stack of your choosing, conceive of and create an application to be presented to the full team in 6 hours.

Keep in mind that I hold my colleagues in extremely high regard; they’re capable, creative, and experienced.  Surely churning out a greenfield demo application would be a laughable exercise done by lunch affording us the rest of the afternoon to take in local culture (read: Czech beer).

So we started to break down the tasks and assign people to ’em:

  • Bootstrap the application codebase
  • Provision a CI environment to build and test
  • Stand up a deployment environment
  • Hook everything together so we’re all looking at the same thing through the dev cycle

We wanted the same conceptual infrastructure we use in delivering Red Hat products and our open source projects – authoritative systems and Continuous Delivery.

And therein lies the problem.  Of the 6 hours spent on this exercise, I noted that every team spent over four and a half hours getting themselves set up and hacked furiously on their real job – the application – in the final sprints.

But that’s not the real problem.

The real problem is that users, all across the globe, have the problem.

And in this moment, it crystallized that it was now our mission to fix this.

Our industry has given developers wonderful tooling, frameworks, and runtimes. With containers, we even have standardized deployment.  And by the way, we require that you load your own containers onto the boat.

We’re missing a unified, cohesive story which brings applications out of the development environment and into service.

Continue reading “Push it Real Good: Continuous Delivery for the people at the push of a button and repo”

Share
Rachel Laycock joins DevNation 2016 as a general session speaker

Rachel Laycock joins DevNation 2016 as a general session speaker

We are pleased to announce that Rachel Laycock, Head of Technology for North America at ThoughtWorks, will be joining us at DevNation 2016 as a general session speaker.  With her background in Agile, Continuous Delivery, and strategy, Rachel is uniquely qualified to explain why CD is more than simply using new tools. This is certainly a relevant topic for everyone – should be fun!

Welcome, Rachel!

Continue reading “Rachel Laycock joins DevNation 2016 as a general session speaker”

Share