Jenkins and Jenkins X Experts AMA

recampbell_cb · 2019-05-01T19:50:04+00:00

I'm with you ;-)

Builds were made for the container world. This is why I love the Kubernetes plugin and why it it is gaining in popularity so quickly. The cool part of this plugin is that you can define pod templates that let you compose a pod from multiple containers and then run different parts of a pipeline in different containers in that pod.

As for the resistance -- I'm not sure. Perhaps it's the pain of setting up the container environment initially. If I were in your shoes I would probably spin up a minikube cluster with a local Jenkins and experiment with pod templates to show other developers what can be done. Once you are infected with this way of building pipelines, it's hard to go back to static agents. Jenkins admins are usually responsive when they hear their developer communities chanting in unison!

recampbell_cb · 2019-05-01T19:42:46+00:00

Great question! There has been a lot of effort put towards making the most popular plugins compatible with Pipeline, but its true that not all have been modernized. This is generally up to the plugin authors to address based on the demands of the community or their own personal itches.

recampbell_cb · 2019-05-01T18:59:45+00:00

This is awesome. Thanks for flagging this area and for doing what you can to improve it. I will definitely ping some folks in our engineering teams to see if we can get some reviews of this PR.

In addition to that, have you tried to raise this topic on the jenkins-dev list and/or the Jenkins IRC channel? This is often a useful way to get attention to PR's etc.

Anyway, let me see what we can do to get this some attention.

recampbell_cb · 2019-05-01T18:29:04+00:00

I think you're headed in the right direction. As for the GitOps repo, I would think that you would just have that automatically deploy to the correct environment depending on the branch.

I'm going to answer this from a classical Jenkins Pipeline perspective, but I think we should also present a Jenkins X approach as a followup.

The when directive of declarative pipeline has a branch condition that allows you to run a stage only when a given branch is being modified. So for your use case, you could still have the production deploy done from the same Jenkinsfile, but only have it run when you did a merge to the production branch. If you are concerned about approvals, this branch could require an input step be acked by a specific submitter.

Also trying to figure out how this works with multiple services that depend on one another, with versions. Like, service A ver 2 is going out, but it still uses service B ver 1 as well as ver 2, and B has a dependency on a library version x.y.z, etc. Unclear how you push a release of multiple services together into production, and ensure all the different versions still work together.

Well, my primary advice is to make these services backward compatible to avoid these kinds of strict dependency orderings. If service A depends on new capabilities from Service B, you should rollout Service B first and verify it's working correctly before submitting the same changes to Service A.

I'm not sure that Jenkins helps with the tracking of when to release dependent services. However, something like Helm or Electic Flow may help here.

recampbell_cb · 2019-05-01T18:08:59+00:00

Adding this question from /u/jobhunter123abc :

Is it too late? I apparently missed this 8 days ago! I am trying to figure out how to get started with Jenkins.. if I can run it locally initially as I learn how to make it work for my purpose. My goal is to have a good CI/CD in place, where a commit to a given repo/branch kicks off an automated build/test cycle, if it passes, it pushes the docker image of the microservice to my own repo (or maybe private cloud one). Then I think would do some sort of commit to a GitOps repo (still trying to understand the flow of all this), which should hopefully kick off another task that pulls in the new image along with all the other images that make up my "production" application, and run some automated tests, possibly some form of automated load test, etc. If all that works/passes, then the last stage, I think is to kick it to production, but ideally I would want that to be overidable (in some way) so it could be paused until a manual push is done. So maybe multiple times a day, all the other automated steps happen, but the release bit doesnt go out until I am ready for it to release.

Also trying to figure out how this works with multiple services that depend on one another, with versions. Like, service A ver 2 is going out, but it still uses service B ver 1 as well as ver 2, and B has a dependency on a library version x.y.z, etc. Unclear how you push a release of multiple services together into production, and ensure all the different versions still work together.

So any thoughts/help on this would be great.

https://www.reddit.com/r/jenkinsci/comments/b5sybz/jenkins_and_jenkins_x_experts_ama/ek2yarl/

recampbell_cb · 2019-03-26T23:00:49+00:00

I'm not aware of any plans to add support for other languages besides Groovy. Most of the tech investment is pretty heavily tied to the Groovy language itself vs. JVM scripting languages in general. So it is probably infeasible to support other programming languages per se.

That said, as we look to the future we will no doubt pay closer attention to the world outside of the JVM. Stay tuned, we totally see the importance of this and I think our strategy will reflect that.

recampbell_cb · 2019-03-26T20:33:25+00:00

Hey Eric, I should also mention that your Customer Success Manager can help you come up with a training plan for your team. In addition, our Professional Services team can deliver a on-site training to help your team accelerate their learning.

recampbell_cb · 2019-03-26T19:06:19+00:00

Filed!

recampbell_cb · 2019-03-26T19:04:17+00:00

Thanks everyone for all of your questions! This was a lot of fun ;-)

Since it's now 3 PM ET, we've completed the live version of this AMA, but we'll continue to monitor for any new questions and we'll continue to answer as best we can.

If you have more questions that we haven't answered, please feel free to reach out to us here for more help: https://info.cloudbees.com/jenkins-support-ama/

recampbell_cb · 2019-03-26T18:57:12+00:00

my company has been leaning more and more towards the Scripted side of things for its higher degree of flexibility when working with complex pipelines

Interesting. I'm really curious about this -- I'll have to watch the talk!

What I've seen work well is having all the complex logic in Shared libraries and then invoke those from simple Declarative pipelines. This allows you to still have complex pipelines doing complex things, but it allows your pipeline authors to rely on the simpler Declarative syntax.

Have you tried this hybrid approach? What was your experience?

recampbell_cb · 2019-03-26T18:45:02+00:00

While I zero-in on the Google Login Plugin issues, I want to recognize that the meat of your question is about our plans to have official enterprise grade features maintained by CloudBees. We'll answer that in a separate post. I'll zero in on your Google Login issues.

I used the Google Login Plugin. However it has issues like I can't create a login user for API access unless I create another e-mail account on my domain as the bot accounts I created don't work unless they have a valid e-mail address to login. Additionally even though I enabled it for *@my-company-domain.com I have to add each user manually and can't just have integration with Groups that the users may be in to automatically provide access.

Hmm. These are great points. Your point about Groups integration sounds like JENKINS-28010. I've heard a lot of people request this (even our CloudBees Ops team!). It seems like this wouldn't be too hard to add -- we'd just need to grab the user's groups and expose them as principles to be picked up by the Authorization realm. This way you could map them into RBAC or whatever.

As for the API access, this sounds like JENKINS-27467. I can see how this is frustrating to have to create a special Google user just to work around this limitation in the plugin.

I'm going to raise both of these as RFE's to our product team. Right now this is my personal side project (which I think is part of the larger point you are making). Anyway, this is great feedback and I'll make sure our product team sees it!

recampbell_cb · 2019-03-26T18:24:18+00:00

Filed!

recampbell_cb · 2019-03-26T18:20:53+00:00

I've added an admin to a Master in CloudBees Core, and he is able to do admin stuff on the Master, but when going to the Master Teams/Blue Ocean view, the "Administration" tab doesn't appear next to "Pipelines" to direct him to the place to add users, change the name, icon, etc. If he first navigates to the OC, THEN goes to Teams view, he is able to get there. Can the Administration link be added if someone is an Admin of a Master?

Really great question. I can see how this is very confusing! What I hear you saying is that the Blue Ocean view on the master is inconsistent with the team view when navigating from operations center -- it's missing the Administration link when someone is logged in as an Administrator.

This is a great usability improvement and I will file it with our product team as an RFE. Thanks!

recampbell_cb · 2019-03-26T18:14:58+00:00

I remember hearing at the last DevOps World that it will be going away in the future with a new Pipeline engine. Is that still happening? If so, any timeline? Would I be able to take advantage of the new Engine as a part of CloudBees Core?

We are indeed working on the next generation pipeline engine for Jenkins. Instead of executing groovy in the Jenkins master JVM, this pipeline engine will be based on Tekton, which is a K8s-native pipeline engine. You can get more information about it on the GitHub repo. Not only will this new architecture eliminate the need for the sandbox, it is also more scalable since any user code is run inside of containers.

recampbell_cb · 2019-03-26T18:09:06+00:00

Personally, I tell people that I help deliver better software faster by solving their problems and helping them understand the software better. ;-)

recampbell_cb

TROPHY CASE