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

@IBMTechnology

2 жыл бұрын

Thank you for the feedback and for being a fan, Rahul! 🙌 Be sure to stay subscribed, we've got more videos coming! 😉

I found the transition between points very fluid and smooth and this made the conclusion very easy to grasp.

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.

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

Awesome explanation. Sweet and concise and up to the point

I don't even know about tekton, I will try it on my next CI/CD project.

Excellent and fluent presentation.

I'm not studying this to work on it; it's just always fascinating to see the parallels of chemistry and computation.

@IBMTechnology

2 жыл бұрын

👍 Stay curious! And thanks for watching!

This channel is the best and the content they provide is awesome.

@IBMTechnology

2 жыл бұрын

Thank you for the appreciation, Pranav!

very good summary :-) Really glad seeing such quality contenct published by IBM

This is so well explained, huge thanks to Christina and IBM Technology YT channel !!!

@IBMTechnology

2 жыл бұрын

Thank you, Davide! We're glad you're enjoying our channel! 😀

Very good explanation, thank you so much !

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.

very helpful video about tekton and jenkins.

Great explanation, One correction though, Jenkins can run within Kubernetes both the masters and slaves and even dynamic slaves on the fly

@Saffat-Hasan

2 жыл бұрын

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

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.

Thanks for this explanation. I am still prefer to use Jenkines. However, it is knowlegable to know the differences between tekton and jenkines.

excellent video, thanks!!

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

Jenkins also offer something called shared libraries which does extend the reuse and one can plug in reusable code into any pipeline

Thank you for this video!

@IBMTechnology

2 жыл бұрын

Glad it was helpful!

Aw I was hoping to see what the actual difference would be. IE showing a working pipeline vs the tekton .yml (.yaml?) structure.

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?

@tirelibirefe

7 ай бұрын

yes, actually I didn't understand what she mean too.

What about jenkins shared library ?

For someone who has dabbled in both Jenkins and Tekton pipelines this video was excellent in helping me understand both CI/CD tools better.

Jenkins has pipeline Library, which allows reuse of steps btw

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.

where can I found full tekton course..? Any full time course available..?

@IBMTechnology

2 жыл бұрын

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! 🙂

Is it good to Build & Test or Test & Build ?? What is the best practices ??

How is tekton different from jenkins x which is another k8s native CI/CD tool ?

@Saffat-Hasan

2 жыл бұрын

Jenkinsx is built on Tekton btw

Are you really writing mirrored? Awesome explanation.

What tech do you use for the reverse writing?

@IBMTechnology

2 жыл бұрын

We shared some backstage "secrets" on our Community page, you can check it out here 👉 ibm.co/3pT41d5

I'm wondering how she can write it in reverse???

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.

Very good video, but unfortunately I can't watch it because of the sound of the pen :/

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?

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.

Test task should be after dev..not before

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

@IBMTechnology

2 жыл бұрын

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! 🙂

@arieheinrich3457

2 жыл бұрын

@@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 u writing backwards?

@IBMTechnology

Жыл бұрын

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.

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.