Red Hat Fuse Integration Service 2.0 tech preview was released a few weeks ago and as it’s based on Red Hat OpenShift 3.3, which has pipeline capability on top of it (tech preview on OpenShift as well), you are able to get one step closer to a more automated and agile continuous integration. As well as, a deployment one-stop platform for us, the integration developer.
Continue reading Automate integration CI/CD process
It’s been a while since Red Hat released version 3.3 of OpenShift Container Platform, this version is full of features.
Continue reading Using Pipelines in OpenShift 3.3+ for CI/CD
Editor’s note: Raffaele Spazzoli is an Architect with Red Hat Consulting’s PaaS and DevOps Practice. This blog post reflects his experience working for Key Bank prior to joining Red Hat.
A recount of the journey from three-months, to one-week release cycle-time.
This is the journey of KeyBank, a super-regional bank, from quarterly deployments to production to weekly deployments to production. In the process we adopted all open source software migrating from WebSphere to Tomcat and adopting OpenShift as our private Linux container cloud platform. We did this in the context of the digital channel modernization project, arguably the most important project for the bank during that period of time.
The scope of the digital channel modernization project was to migrate a 15-year old Java web app that was servlet-based, developed on a homegrown MVC framework and running on Java 1.6 and WebSphere 7.x to a more modern web experience and to create a new mobile web app.
This web app had grown more expensive to maintain and to meet our SLAs. It was the quintessential monolith app. Our architectural objective was to create an API layer to separate the presentation logic (web or mobile) from the business logic — what lay ahead was an effort to completely modernize the continuous integration and deployment process.
Continue reading “The fast-moving monolith: how we sped-up delivery from every three months, to every week”
In order for businesses to stay agile, developers must be able to deploy apps — quickly, efficiently, and in a streamlined manner. Red Hat Open Innovation Labs uses a container-driven application development framework to perform continuous delivery and accelerate innovation.
Continue reading Red Hat Open Innovation Labs: Automating CI/CD Deployment Pipelines
One of the greatest advantages of using docker containers is the fact that you can move them between environments. A promotion from Development to a Production environment, shouldn’t take more than some few seconds. This is one aspect of “Continuous Delivery”
Because Microservices Architectures are “independently replaceable and upgradeable”, they are the best scenario to show a “Deployment Pipeline”.
Red Hat Developers has produced a sample and free application called “Red Hat Helloworlds MSA” that demonstrates different aspects of microservices (You can read more about this application in the following post: Have your own Microservices playground). This application shows how you can independently deploy the microservices using different technologies (JAX-RS and WildFly Swarm, Spring-boot, Vert.X, NodeJS, etc) and how you can use different invocation patterns to integrate them. It also uses Netflix OSS, integrated via Kubeflix, and ZipKin for tracing.
Continue reading “Microservices CI/CD Pipelines in Openshift”
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”
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”