Jean-Marcel Belmont

+ Follow
since Sep 26, 2018
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jean-Marcel Belmont

Sorry everybody but it looks like I got swapped with John Horton, I didn't write this book unfortunately but John Horton did
3 years ago
Hello Everyone,

Thanks for all the great participation in the past several days. I received a lot of great questions.
I hope the book is insightful for you all.

3 years ago
Hello Ren,

Yeah I totally understand on the Jenkins side. If you are already have Jenkins in place in your workplace there isn't too much advantage to reading the chapters on Circle CI and Travis CI although it would be good to know them if you ever open source some projects as these CI tools are heavily used in Github and Bitbucket.

3 years ago
Hello David,

Thank you kind words

3 years ago
Hello David,

To answer your questions about CI/CD with respect to containers, I cover how tools such as Jenkins 2.0 utilize containers with the pipeline syntax in Chapter 8.
In chapter 8 I cover how Jenkins 2.0 (Blue Ocean) guides you to using Containers but the intent of the chapter is how to use Jenkins 2.0 and the navigate the new UI and understand the pipeline syntax.

In the chapters for Travis CI and Circle CI I demonstrate how to use containers build your own docker images and run them. So to answer your question Jenkins 2.0, Travis, and Circle CI are already guiding you to using Containers, so I cover how to containers with these specific CI tools.

I don't go over Openshift in the book that to me seems like it could be its own book to be honest, the tagline for Openshift is Red Hat OpenShift helps teams deliver faster with containers and Kubernetes and I don't cover Kubernetes in the book.

To answer your question about DevSecOps in Chapter 15 I briefly cover best practices with CI/CD and password and secrets management but in all fairness this could also be an entire book.

I hope this answers your questions.

3 years ago
Hello Adriano,

Interesting question you propose here. Since you are asking my opinion I will say that using Continuous Integration / Continuous Delivery is much more of a risk than not using CI/CD methodologies.

I say this for a couple of reasons:

Manually processes such as running test suites in a local machine versus in a clean CI build can be problematic. You might have certain environment variables set in your local machine, a work of art that only is properly configured in your machine.
Working on a team of any size you want an independent machine that can have declarative steps on how to be configured and what environment variables to set and jobs to kick off. If you were to try to do this outside of CI/CD methodologies you run the risk of missing a step in a manual process. CI/CD really ties in with the concept of automation and you can have multiple builds that serve in the Deployment Pipeline. The more automation you have in place along with CI/CD processes you can economies of scale in delivering a quality product to your customers/end users.
It is not that manual processes are evil but just that they are not repeatable and reproducible like automated processes are.

You can certainly use PHP in Travis CI and other CI/CD products, I believe that Jenkins has a plugin for Cold Fusion that you can use not totally sure on that but all in all CI/CD is a very important process.

Anyways I hope this answers your questions,

3 years ago
Hello Jeanne,

Yes that is why I added the chapter for building Jenkins Plugins, just in case you need to know how to, but for the most part you won't need to because of the large offering of Jenkins Plugins

3 years ago
Hello Kumar,

So I would say that CI/CD approaches whether on premise or in the cloud will share certain characteristics. Like for example having an automated test suite that is triggered through version control should be a common theme.
If you are using Jenkins for example you have the ability for much more fine grain customization than if you use Travis CI and Circle CI which are more often used with Open Source projects and with Bitbucket and Github for example.
Whether you use Travis CI, Circle Ci or Jenkins for example you still want to have fast builds with a good test suite composed of Unit and Integration Tests, have code linting and style checking, and a possible compilation step with application binary versioning.

One of the most important things that you want with your CI Build is that the feedback loop is fast, if a code change has caused some breakage you want your CI build to immediately notify you.
You can easily setup Jenkins to watch for code changes pushed to a remote repository. Anyways I hope this answers your question.

You can have additional builds for an Acceptance Test Suite, Load Test, perhaps a suite of security tests. All of these builds should be automated and part of a larger Deployment Pipeline and if you follow Continuous Delivery these automated build should serve as quality gates where you may not necessarily be deploying continuously but your software has gone through a series of automated builds.

3 years ago
Hello Paul,

Thanks for the kind words.

So for many of the chapters I have an example repo either in bitbucket or github to illustrate examples.
The first 4 chapters are meant to be the foundational aspect to elaborate on Continuous Integration, Continuous Delivery and Automation, but you don't necessarily have to read the book cover to cover.

You could certainly skip around the book so if you are just interested in Jenkins there is several chapters on Jenkins and likewise for Travis CI and Circle CI.

3 years ago
Hi Run,

The reason I added a chapter on writing a plugin for Jenkins was to demonstrate how to write a plugin if necessary.
Obviously though there is a whole world of Jenkins Plugins available so the likelihood that a Jenkins Plugin exists that you need is already there.

To answer your question though, Jenkins is a CI tool that you can use for many different things.

You mention svn but you can also use git and mercurial which are distributed version control systems unlike svn which is a centralized version control system.
You can use many different types of Jenkins plugins outside of jUnit but to be more precise you can use Jenkins for many different types of tests such as Unit Tests, Integration Tests, and Acceptance Tests.
You can use Jenkins to make Code Coverage Reports and to generate other types of reports.

I would argue that yes you will get a lot out of the Travis CI and Circle CI chapters as they are heavily used in open source projects and there are differences between them and Jenkins.
Namely the way you configure Travis CI is through an embedded configuration file such as yaml.

Anyways thanks for the Questions
3 years ago
Thank you Carl for the great question
3 years ago
Hello Matt,

The new Jenkins Pipeline with Jenkins 2.0 is a great improvement to old Jenkins Freestyle scripting.

So in the book I do cover some Jenkins Plugins and I spent several chapters covering how to use Jenkins Freestyle scripts, the new Jenkins Pipeline Syntax.
I try to tie in the concepts of Continuous Delivery throughout chapters.
I don't cover for example SonarQube as you mention here but I do over best practices in a commit build.
One of the main emphasis I try to make in the book is the power of automation of manual processes, so I do go over Code Coverage, Unit Testing, Automated Acceptance Testing and concepts in DevOps.

I spend a good amount of time going over the fundamentals of CI/CD and I use Jenkins, Travis CI, and Circle CI as the vehicles to talk about CI/CD.
3 years ago
Hello Jorge,

So throughout the book I both mention and stress concepts from DevOps such as Automation. The focus of the book are principles in Continuous Integration and Delivery.

Other question, In my project we are using Confluence, Jira, SVN and producing a new release of the system each month.  
Each release includes integration testing (manual by testing team), defect fixes. There is no automated unit testing. But we have a form of "unit test".

Would you say that we are doing continuous integration and delivery?

Remember that a Continuous Integration (CI) build is almost like a recipe. You tell it what to do on each build. If a build is fired on each commit build then you have CI setup.
I would say that I have an Automated Unit Test Suite is a fundamental part of good CI Builds. You want your CI Builds to be fast running so that you have a shorter feedback loop but you also want to instill good practices that you can enforce.
An automated unit test suite, code linting, static analysis a compilation step would be a good first step in the CI/CD pipeline.

The concept of Continuous Delivery is the point at which you deliver a software product to your end users.
A product is only useful if your intended users can actually use the product.

Here is a illustration of a CI/CD pipeline.

You really need a strong test suite base and have other types of checks in your greater deployment pipeline in order to get quality software to get to Continuous Delivery. Remember that Continuous Delivery is not Continuous Deployment since you are automatically releasing software after all these quality gates pass.

Here is a good testing pyramid diagram to look at.

In order to practice Continuous Delivery you should look at how your current Deployment Pipeline is functioning and see where you can add automation in place of manual practices to make changes reliably.
3 years ago
Continuous Integration:

Continuous Integration can be viewed as a software engineering task where source code is merged and tested in a version controlled project such as Git.

Usually a Continuous Integration Build is triggered via source control management, meaning a developer pushes a commit to a version control system such as git.

A Continuous Integration Build is more than just a compilation step. It can consist of a compilation step, a testing phase, a code inspection phase, and a deployment phase.

A Continuous Integration Build can act as a kind of verification step that checks that your software is working as a cohesive unit.

Continuous Delivery

Continuous Delivery (CD) is the point at which you deliver a software product to your end users.

A product is only useful if your intended users can actually use the product.

CI/CD will tie into a Deployment Pipeline, I have attached visual on a possible deployment pipeline but think about CI/CD as a tool for shipping a feature to an end user/customer.

3 years ago