Join us for the next online DevNation Live on Thursday, July 19th at 12pm EDT for Container pipeline master: Continuous integration + continuous delivery with Jenkins, presented by Red Hat principal technical product marketing manager for Red Hat OpenShift, Siamak Sadeghianfar.
In this session, we’ll take a detailed look into how you can build a super slick, automated continuous integration and continuous delivery (CI/CD) Jenkins pipeline that delivers your application payloads onto the enterprise Kubernetes platform, Red Hat OpenShift. You see how zero-downtime deployment patterns can be part of your release process when you are using a container platform based on Kubernetes.
Automating your build, test, and deployment processes can improve reliability and reduce the need for rollbacks. However, we’ll show you how rollbacks can be handled too.
Register now and join the live presentation at 12pm EDT, Thursday, July 19th.
Continue reading “July 19th DevNation Live: Container pipeline master: Continuous integration + continuous delivery with Jenkins”
Typical CI process (source: www.pepgotesting.com)
Continuous Integration (CI) is a phase in the software development cycle where code from different team members or different features are integrated together. This usually involves merging code (integration), building the application and carrying out basic tests all within an ephemeral environment.
Continue reading “Continuous Integration: A “Typical” Process”
I’m thrilled to announce the availability of a mini-book about Eclipse Vert.x. This book focuses on the development of reactive microservices in Java and covers reactive systems and reactive programming.
Writing a book, even for a mini-book is a tough task. While writing code and writing a book are very different experiences, you can apply the same process and good practice. I would like to list a couple of tips I’ve used to make the writing a bit easier.
Continue reading “Continuously Building a Book”
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
In the current world of DevOps, Continuous Delivery, Microservices, and PaaS many organizations want to know how Software Governance practices and requirements fit. Some of this comes from a regulatory perspective, ensuring compliance (e.g HIPAA/PHI, SOX, PCI) and auditing requirements are met. Another perspective focuses on existing technology standards, design practices, and application architecture. At the same time developers and teams are being told to be more agile, adaptable, and self-directed. How do we achieve the latter while mitigating the risks associated with the former?
I would argue that a “Descriptive” approach to Software Governance is required. In my perfect world, Solution Architectures are monitored for exception as they progress through the delivery process. The technical underpinnings of systems, in terms of infrastructure and software, are “described” in code and configuration that can be easily audited against established policies. The runtime implementation of a particular solution is then transparent to all interested parties. In many ways, this is just an extension of Open Source practices to the delivered solutions and systems themselves.
Continue reading “Shouldn’t Software Governance Practices be more Descriptive than Prescriptive?”
The Journey to Delivery Efficiency
For as long as I can remember in my career in the Information Technology industry, there’s been talk about faster time-to-market, reduced waste, ideas on how to exceed (or simply meet) customer expectations. You get the picture. This notion of how to do things faster, maintain quality and give the customer what they want is proclaimed in the practices of Lean, Lean Six Sigma, Agile Development (including Scrum, Kanban, and Scrumban), Incremental Development, XP (Extreme Programming), Test Driven Development, and DevOps, to name a few (whew!). What strikes me, though, is that the faster we try to deliver solutions, the more likely I am to hear things like “let’s just get started” or “we don’t really need architecture”. An example I heard a few weeks ago in a meeting between a consultant and a project delivery team:
Continue reading “Faster, Better, Stronger, Wiser”
In Part 1, we talked a bit about this DevOps thing and why people won’t stop talking about it. In Part 2, we’ll talk about the areas where you can change your IT focus today to help benefit from DevOps.
A classic mistake is to focus primarily on the tools associated with successful DevOps shops. It’s not as if you can bring up your own Deployinator and suddenly become as high-functioning an IT shop as Etsy. The tooling is important, but won’t succeed if used for its own sake. The most relevant tooling is used to support a culture that can consume it effectively.
Continue reading “DevOps in Straight English – Part 2 of 2”
If you’re like me, you may be suffering a bit of buzzword fatigue, especially relating to how this word is used (or misused) within the IT community. But for those of us who have been a part of the community for awhile, it holds deeper meaning than the oft repeated platitude of “Software Developers and Sysadmins working together, riding unicorns over rainbows“. Okay, while I may have gotten slightly carried away, you get the point.
What is DevOps to the broader community that embraces it, and is helping even now to define it? What does that even mean for Red Hat’s IT efforts? We’re going to dive deeper into both questions in this installment.
Continue reading “DevOps in Straight English – Part 1 of 2 – Enter the Buzzword”
This is our new Red Hat Developer Newsletter that launched last month. Please register for this and receive a summary of important Red Hat developer news. The January issue will be going out soon!
This is part 3 of a three part article on Continuous Integration Strategies: Simplifying application development on Red Hat® Enterprise Linux®
The testing environment requirements are simplified somewhat if your software is built against a Red Hat Software Collection (RHSCL).
Red Hat Software Collections provide three primary features: the ability to have multiple versions of software on one OS, certainty that the software is the same across versions of the OS, and the option to refresh components more frequently than the underlying OS.
As a result, testing need only be performed against the software collection for which the application has been built—so an application developed to run on the software collection for Python 2.7 should be testable on that software collection running on any version of Red Hat Enterprise Linux. The test results should then be valid for all versions of Red Hat Enterprise Linux that run that software collection.
REQUIREMENTS FOR TESTS
Test coverage within the CI environment should be considered no differently than any other integration and testing regime. Your tests should provide an appropriate breadth of coverage and depth in test scenarios to ensure the necessary level of quality in the delivered software.
Continue reading “Continuous Integration Strategies (Part 3 of 3)”