Building microservices isn’t merely breaking up a monolithic software application into a collection of smaller services. When shifting to microservices, there are best practices developers must adopt. It becomes equally important to learn microservices development best practices, optimizing which languages to use, using an opinionated stack and pre-configured pipeline, and testing apps using continuous deployment. Hence, it’s also about automation and the method for developing software.
With too many services interacting with each other through APIs, it introduces complexity, which is generally considered to be the primary foe of good software. In a microservices architecture, an individual service concerns itself only with minimal responsibilities. If a single service develops a problem, it’s much easier to rewrite that single service than rewrite and merge-in a fix to the entire monolith. Hence, one needs to maintain the ever-growing release cycle which becomes more frequent as compared to the old monolithic architecture. To allow our DevOps teams to deploy and test their microservices directly over Cloud and multiple times per day, a robust continuous integration and delivery tool is required.
Today, DevOps is a set of practices which mainly focuses on reducing the time between committing a change to a system and the change being placed into normal production, while ensuring better quality. Teams should be able to deploy multiple times per day compared to the industry average that falls between once per week and once per month. The lead time for code to migrate from ‘code committed’ to ‘code in production’ should be less than one hour and the change failure rate should be less than 15%, compared to an average of between 31-45%. In nutshell, MTTR (mean time to repair) from a failure is expected to be less than one hour.
Jenkins is one such continuous integration and continuous delivery tool which can be used to automate building, testing, and deploying software. It is an open-source automation server that lets you flexibly orchestrate your build, test, and deployment pipelines. It has extensive community support, heavily Java-based codebase making it portable to all major platforms. It has a rich ecosystem of more than 1000 plugins (there’s even a Jenkins plugin for TestProject too ?). Jenkins works well with all popular Source Control Management systems like Git, SVN, Mercurial and CVS. It works well with popular build tools like Ant, Maven & Grunt. Jenkins plugins provide support for technologies like Docker and Kubernetes, which enable the creation and deployment of cloud-based microservice environments, both for testing as well as production deployments.
Jenkins works perfectly well as a stand-alone open source tool, but with the shift to Cloud native and Kubernetes, it invites challenges in terms of management and operation. Recently, Jenkins X has emerged as a way to improve and automate continuous delivery pipelines to Kubernetes and cloud native environments. To achieve speed and agility, it is important to automate all the testing processes and configure them to run automatically over the Kubernetes cluster. To enhance the automation testing capabilities independently and within DevOps, TestProject comes to the rescue ??
In this tutorial, we will discuss what is Jenkins X and review its architecture and benefits. We will also demonstrate how to set up Jenkins X on Google Cloud Platform and then integrate it with TestProject in a seamless manner.
Table of Contents
- Why Jenkins X?
- Compelling Features of Jenkins X
- Jenkins X Architecture
- Introducing JX CLI
- Jenkins X Prerequisites
- Installing JX
- Creating Kubernetes Cluster using JX
- Verifying Kubernetes Cluster
- Clone the Jenkins X Boot Configuration Repository
- Running JX Boot CLI
- Getting Jenkins X Environment
- Bringing up Jenkins X GUI
- Jenkins X Integration with TestProject
- Conclusion
Why Jenkins X?
Read the article tutorial at TestProject.io
Comments are closed.