Just love how crystal clear explanation are available on this channel, been watching for past 1 years whenever I need to get some basic understanding of cloud technologies and tools
Wasn't convinced switching over after watching this video. But after working on Tekton (Openshift 4 pipeline), I am impressed. You create the task once... and you can re-use it over and over and over again for all other projects I created a simple diagram flow here: [Git Clone] - which I'll specify the parameter URL to point to my bitbucket project -> [NPM] - which I'll name "npm-install" and set the parameter GOALS = "install" -> [NPM] - which I'll name "npm-test" and set the parameter GOALS = "run test" -> [NPM] - which I'll name "npm-build" and set the parameter GOALS = "run build" Define the task "NPM" once... use it everywhere for your company. To avoid creating 3 "NPM" tasks (install, run test, run build, etc), use parameters to allow this single "NPM" task to by dynamic and capable of running any tasks specified. For example, on the NPM, I specified: "string GOALS" - which will be appended to after the "npm" args e.g. "npm ${GOALS} "string CONTEXT_PATH" - which allows user to specify the relative path where the package.json is located I set default to "." but allow user to change it on the fly to "src/main/webapp" for instance... Very impressive. Glad I gave it a chance.
Regarding reusability: Jenkins also allows defining reusable components in Pipeline Libraries. These libraries can contain very small elements but also complete, parametrizable pipelines as well. When you are using Pipeline Libraries, your actual Jenkinsfiles can be very-very short because it only references library components and parametrizes them. Enterprise level scalability Jenkins itself can run on Kubernetes nicely, there are Helm charts for that. Jenkins also has a fairly sophisticated Kubernetes plugin so that you can run your build stages in dynamically created build pods on the cluster it is installed into or in other remote Kubernetes clusters.
I'm using Jenkins which is running in my Kubernetes cluster. Each Jenkins job is located separately in different Jenkinsfile, and I have 1 pipeline Jenkinsfile that connects all those different jobs together. At least with my configuration if I have a docker container build job, I can reuse it by referring to it in another Jenkinsfile for a different job. Came across this because I was interested knowing what Tekton was, loved the explanation. Cheers
EVERYTHING explained on tekton is basically Jenkins. Creating a big jenkins file is BAD best practice. You split it to using shared libraries. EVEN the fact tekton runs on pods, can be achieved with slaves running in containers and jenkins engine itself running in a container, and using mounted volumes where you store the folder structures and files (doesnt that sound like PVC) you can get higher availability. All you need is to use kubctl and security admin access to the k8s control plance stored as secrets. This is not a good explanation of what tekton benefits are. If you compare it to a BADLY configured and maintained Jenkins, then obviously anything will be better. If you compare it to a well configured, it actually gives a far better solution than tekton as youre more likely to have lot more workloads that dont need k8s, and then the investment you did in tekton can NOT be shared to other types of workload where in jenkins its just another job with other CLI/Command. Comparing apples to oranges, doesnt make apples better then oranges, its just another fruit.
Yeah but it's not quite kubernetes native. I've had some issues with scalability regarding the maximum number of concurrent connections that the orchestrator can handle. This only occurs if the master instances are shared which isn't that unusual of a use case considering how large they are to start with
The large Jenkinsfile is slightly misleading because it's very possible to re-use existing code by creating a library (i.e. see SAP's jenkins-library). There was also little mention of how frustrating Jenkins plugin architecture is. Updating any Jenkins plugin requires *restarting* Jenkins, so any running jobs could be impacted. Pipeline state can be serialized to disk after being paused, but resuming from a paused state is not always a safe operation. Also, Jenkins is a singleton and creating a HA failover is not an easy task.
Thanks for the clear explanation, great video. Having said that, I find Tekton quite frustrating. Just getting it to work with OKD (maybe there is a smoother experience with OpenShift) is a bit of trouble and then once that is sorted, I found the learning curve quite steep. Jenkins was a lot easier to learn and handle. I also found the Jenkins documentation a lot more concise compared to Tekton.
The whole single file discussion of Jenkins is a bit incorrect... since actual stage actions/work can be considered a Groovy method, one can easily put those methods in separate files/libraries, which you can then call for/load when needed. Sure, the whole pipeline would still be defined in a single file, similar to Tekton's, but it's going to be calling methods defined elsewhere, same as in most Java/Groovy or other programming languages. The difference I can see is that of more open and programmer oriented stage work definitions Java devs could be more accustomed to in Jenkins, while Tekton is more YAML solutions-like SREs and Kubernetes/Ansible admins would find easier to grasp and organise efficiently.
I completely agree with you. This video is quite biased and the presenter does not understand Jenkins quite well. People hate Jenkins because one needs to code in groovy. But, they fail to understand the power that comes with programming than mere YAML. In terms of organisation of code and reusability, I guess it can be cleverly achieved in Jenkins as well. One just need to know how to do that.
Very good explanation. I'm an engineer for TeamCity and now for tekton. I was glad to had this when I started my tekton journey. Only thing I'm a little confused is "testing before building"? Or do you mean building images?
I like the idea of Tekton, however it is very verbose to do even the simplest of things. Jenkins declarative pipelines are so much easier to use and write and can still drive k8s pods to do the actual work in the same way.
Hi there! We don't have a dedicated course for Tekton at the moment, but be sure to check the links in this video's description for more resources (videos, Kubernetes lab etc.) ⤴️ Also, here's our IBM Tekton page with more info ➡️ ibm.co/3qXVLsV Hope this helps! 🙂
I am a little bit disappointed on this video where it did not address the elephant in the room, why do we choose Tekton over Jenkins, what it’s good for, what’s the limitations
Hi there! While the whole video is trying to explain just that, the advantages are summarized at min. 14:15. What other info would you need exactly? Please also check out the additional links in the video's description, to see more on Tekton. ⤴️ Hope this helps! 🙂
@@IBMTechnology Thats a bad summary to being with as the points mentioned can be achieved in jenkins. The only difference is you assume everyone running jenkins on VMs. I run on docker and most of my slaves are in containers, unless i need physical usb devices to test hardware. The only plus i see is that you dont need groovy, although if you use share libraries correctly you can have all your pipeline just being multiple python scripts for that matter so even that point is muted. I agree with OP, the REAL decisions considerations are not really presented.
Actually the key question wasn't answered. Jenkins means Groovy, I have seen many organizations which want to get rid of Jenkins. Groovy turns Jenkins to a nightmare. For Tekton pipelines, is any programming language experience something like Groovy needed?
Writing all your logic in one Jenkinsfile is bad practice. You can use a shared library and reuse your logic. Also you can have a very structured solution with shared libraries in Jenkins.
I don't like Jenkins as it's difficult to configure, but in this video you make it seem as it is not possible to have organized pipelines in Jenkins. That's just not true. In jenkins you are writting code. If you don't know how to organize code, that's on you and is not a problem of the tool.
I was really appalled by the presenter's knowledge about Jenkins. If you are looking for a comparison between Jenkins and Tekton, this is not the video you should refer to.
Just love how crystal clear explanation are available on this channel, been watching for past 1 years whenever I need to get some basic understanding of cloud technologies and tools
Thank you for the feedback and for being a fan, Rahul! 🙌 Be sure to stay subscribed, we've got more videos coming! 😉
Wasn't convinced switching over after watching this video.
But after working on Tekton (Openshift 4 pipeline), I am impressed.
You create the task once... and you can re-use it over and over and over again for all other projects
I created a simple diagram flow here:
[Git Clone] - which I'll specify the parameter URL to point to my bitbucket project ->
[NPM] - which I'll name "npm-install" and set the parameter GOALS = "install" ->
[NPM] - which I'll name "npm-test" and set the parameter GOALS = "run test" ->
[NPM] - which I'll name "npm-build" and set the parameter GOALS = "run build"
Define the task "NPM" once... use it everywhere for your company.
To avoid creating 3 "NPM" tasks (install, run test, run build, etc), use parameters to allow this single "NPM" task to by dynamic and capable of running any tasks specified.
For example, on the NPM, I specified:
"string GOALS" - which will be appended to after the "npm" args
e.g. "npm ${GOALS}
"string CONTEXT_PATH" - which allows user to specify the relative path where the package.json is located
I set default to "." but allow user to change it on the fly to "src/main/webapp" for instance...
Very impressive.
Glad I gave it a chance.
I found the transition between points very fluid and smooth and this made the conclusion very easy to grasp.
Regarding reusability:
Jenkins also allows defining reusable components in Pipeline Libraries.
These libraries can contain very small elements but also complete, parametrizable pipelines as well.
When you are using Pipeline Libraries, your actual Jenkinsfiles can be very-very short because it only references library components and parametrizes them.
Enterprise level scalability
Jenkins itself can run on Kubernetes nicely, there are Helm charts for that.
Jenkins also has a fairly sophisticated Kubernetes plugin so that you can run your build stages in dynamically created build pods on the cluster it is installed into or in other remote Kubernetes clusters.
I'm not studying this to work on it; it's just always fascinating to see the parallels of chemistry and computation.
👍 Stay curious! And thanks for watching!
I'm using Jenkins which is running in my Kubernetes cluster. Each Jenkins job is located separately in different Jenkinsfile, and I have 1 pipeline Jenkinsfile that connects all those different jobs together. At least with my configuration if I have a docker container build job, I can reuse it by referring to it in another Jenkinsfile for a different job.
Came across this because I was interested knowing what Tekton was, loved the explanation. Cheers
This channel is the best and the content they provide is awesome.
Thank you for the appreciation, Pranav!
EVERYTHING explained on tekton is basically Jenkins. Creating a big jenkins file is BAD best practice. You split it to using shared libraries. EVEN the fact tekton runs on pods, can be achieved with slaves running in containers and jenkins engine itself running in a container, and using mounted volumes where you store the folder structures and files (doesnt that sound like PVC) you can get higher availability.
All you need is to use kubctl and security admin access to the k8s control plance stored as secrets.
This is not a good explanation of what tekton benefits are. If you compare it to a BADLY configured and maintained Jenkins, then obviously anything will be better. If you compare it to a well configured, it actually gives a far better solution than tekton as youre more likely to have lot more workloads that dont need k8s, and then the investment you did in tekton can NOT be shared to other types of workload where in jenkins its just another job with other CLI/Command.
Comparing apples to oranges, doesnt make apples better then oranges, its just another fruit.
This is so well explained, huge thanks to Christina and IBM Technology YT channel !!!
Thank you, Davide! We're glad you're enjoying our channel! 😀
I don't even know about tekton, I will try it on my next CI/CD project.
very good summary :-) Really glad seeing such quality contenct published by IBM
For someone who has dabbled in both Jenkins and Tekton pipelines this video was excellent in helping me understand both CI/CD tools better.
Great explanation, One correction though, Jenkins can run within Kubernetes both the masters and slaves and even dynamic slaves on the fly
Yeah but it's not quite kubernetes native. I've had some issues with scalability regarding the maximum number of concurrent connections that the orchestrator can handle.
This only occurs if the master instances are shared which isn't that unusual of a use case considering how large they are to start with
The large Jenkinsfile is slightly misleading because it's very possible to re-use existing code by creating a library (i.e. see SAP's jenkins-library).
There was also little mention of how frustrating Jenkins plugin architecture is. Updating any Jenkins plugin requires *restarting* Jenkins, so any running jobs could be impacted. Pipeline state can be serialized to disk after being paused, but resuming from a paused state is not always a safe operation.
Also, Jenkins is a singleton and creating a HA failover is not an easy task.
Jenkins also offer something called shared libraries which does extend the reuse and one can plug in reusable code into any pipeline
Excellent and fluent presentation.
Thanks for the clear explanation, great video. Having said that, I find Tekton quite frustrating. Just getting it to work with OKD (maybe there is a smoother experience with OpenShift) is a bit of trouble and then once that is sorted, I found the learning curve quite steep. Jenkins was a lot easier to learn and handle. I also found the Jenkins documentation a lot more concise compared to Tekton.
Awesome explanation. Sweet and concise and up to the point
It's not true that Jenkins pipeline can be managed using GUI only. You can have very flexible scenario using Groovy and have it under VCS
Aw I was hoping to see what the actual difference would be. IE showing a working pipeline vs the tekton .yml (.yaml?) structure.
Jenkins has pipeline Library, which allows reuse of steps btw
Very good explanation, thank you so much !
Thank you - great video!
Thanks for this explanation. I am still prefer to use Jenkines. However, it is knowlegable to know the differences between tekton and jenkines.
very helpful video about tekton and jenkins.
Is it good to Build & Test or Test & Build ?? What is the best practices ??
What about jenkins shared library ?
The whole single file discussion of Jenkins is a bit incorrect... since actual stage actions/work can be considered a Groovy method, one can easily put those methods in separate files/libraries, which you can then call for/load when needed. Sure, the whole pipeline would still be defined in a single file, similar to Tekton's, but it's going to be calling methods defined elsewhere, same as in most Java/Groovy or other programming languages. The difference I can see is that of more open and programmer oriented stage work definitions Java devs could be more accustomed to in Jenkins, while Tekton is more YAML solutions-like SREs and Kubernetes/Ansible admins would find easier to grasp and organise efficiently.
I completely agree with you. This video is quite biased and the presenter does not understand Jenkins quite well. People hate Jenkins because one needs to code in groovy. But, they fail to understand the power that comes with programming than mere YAML. In terms of organisation of code and reusability, I guess it can be cleverly achieved in Jenkins as well. One just need to know how to do that.
Very good explanation. I'm an engineer for TeamCity and now for tekton. I was glad to had this when I started my tekton journey. Only thing I'm a little confused is "testing before building"? Or do you mean building images?
yes, actually I didn't understand what she mean too.
excellent video, thanks!!
Thank you for this video!
Glad it was helpful!
I like the idea of Tekton, however it is very verbose to do even the simplest of things. Jenkins declarative pipelines are so much easier to use and write and can still drive k8s pods to do the actual work in the same way.
where can I found full tekton course..? Any full time course available..?
Hi there! We don't have a dedicated course for Tekton at the moment, but be sure to check the links in this video's description for more resources (videos, Kubernetes lab etc.) ⤴️
Also, here's our IBM Tekton page with more info ➡️ ibm.co/3qXVLsV
Hope this helps! 🙂
I am a little bit disappointed on this video where it did not address the elephant in the room, why do we choose Tekton over Jenkins, what it’s good for, what’s the limitations
Hi there! While the whole video is trying to explain just that, the advantages are summarized at min. 14:15. What other info would you need exactly?
Please also check out the additional links in the video's description, to see more on Tekton. ⤴️
Hope this helps! 🙂
@@IBMTechnology Thats a bad summary to being with as the points mentioned can be achieved in jenkins. The only difference is you assume everyone running jenkins on VMs. I run on docker and most of my slaves are in containers, unless i need physical usb devices to test hardware. The only plus i see is that you dont need groovy, although if you use share libraries correctly you can have all your pipeline just being multiple python scripts for that matter so even that point is muted. I agree with OP, the REAL decisions considerations are not really presented.
Are you really writing mirrored? Awesome explanation.
So if i get this right the main selling point of Tekton is that it runs on Kubernetes while Jenkins needs VMs directly with Java....
Jenkins can (and IMO should be) run within a container, hence can run in Kubernetes.
What tech do you use for the reverse writing?
We shared some backstage "secrets" on our Community page, you can check it out here 👉 ibm.co/3pT41d5
How is tekton different from jenkins x which is another k8s native CI/CD tool ?
Jenkinsx is built on Tekton btw
Actually the key question wasn't answered.
Jenkins means Groovy, I have seen many organizations which want to get rid of Jenkins. Groovy turns Jenkins to a nightmare.
For Tekton pipelines, is any programming language experience something like Groovy needed?
Very good video, but unfortunately I can't watch it because of the sound of the pen :/
I'm wondering how she can write it in reverse???
Test task should be after dev..not before
Writing all your logic in one Jenkinsfile is bad practice. You can use a shared library and reuse your logic. Also you can have a very structured solution with shared libraries in Jenkins.
Are u writing backwards?
Search on "lightboard videos".
I don't like Jenkins as it's difficult to configure, but in this video you make it seem as it is not possible to have organized pipelines in Jenkins. That's just not true.
In jenkins you are writting code. If you don't know how to organize code, that's on you and is not a problem of the tool.
I was really appalled by the presenter's knowledge about Jenkins. If you are looking for a comparison between Jenkins and Tekton, this is not the video you should refer to.