first draft of a new JEP: Jenkins X: Jenkins for Kubernetes CD

[James Strachan]

I've just submitted a draft of a new JEP: https://github.com/jenkinsci/jep/pull/62

You can read the JEP in full here:

https://github.com/jstrachan/jep/blob/jx/jep/400/README.adoc

I hope this makes sense & some of you find it interesting. I'd love feedback if anyone has any! 

I'll try blog more about it next week to give a more complete picture of the current functionality in the current prototype. 

--

James
-------
Twitter: @jstrachan
Email: james.s...@gmail.com

Blog: https://medium.com/@jstrachan/

[Liam Newman]

Thanks, James! 

This has been approved as Draft.  Going forward the current version can be viewed here:

https://github.com/jenkinsci/jep/blob/master/jep/400/README.adoc

Please continue to discuss in this droup and submit pull requests as needed.  

Thanks,

Liam Newman

JEP Editor

[Kohsuke Kawaguchi]

Thanks James,

This is an important and exciting JEP for me, because it sets the mission & scope for a new project “Jenkins X.”

Starting from Jenkins 2, in contributor events and Jenkins Worlds, I’ve always pitched that our Jenkins project needs to take a bigger role and responsibility in serving our users and solving their challenges. Historically, by and large we did it by writing plugins, but we’ve been so successful in doing that, now we need to create solutions that combine those plugins.

I said “starting from Jenkins 2” because the default recommended set of plugins, initial setup wizard to start Jenkins more securely, and so on was the first step toward us doing more than writing plugins.

Blue Ocean followed, in which we focused on important parts of Jenkins and provided great UX for that. It decidedly blended together feature areas that are internally provided by a whole bunch of different plugins, but users see much less seam between them now.

Jenkins Essentials, which Tyler posted in recent weeks, is one more step forward. That project is aiming to take an even bigger responsibility in keeping people’s Jenkins instances up and running, and further de-emphasize individuality of plugins and emphasize the combined solution.

I see Jenkins X very much on this same path. Jenkins X brings a different aspect to building a solution — it focuses on a specific vertical area, a Kubernetes application development, and really drastically simplify the software development by bringing together Jenkins, a whole bunch of plugins, the opinionated best practice of how you should use Kubernetes.

Especially early in the days of Jenkins, this kind of integration was done by heroic Jenkins admins and provided for the organizations they were working in, but they were never really shared upstream in the community. So we all had to re-invent that.

Jenkins X is a significant step because it is trying to bring those hard-earned integration work back into the community. It makes Jenkins approachable and valuable to a whole new set of users who are not currently using Jenkins.

From that perspective, I hope more projects like this will follow, in different domains of software development. This is a little bit like how Eclipse has evolved from just a Java IDE to an umbrella of projects.

On top of all that, the icing on the cake, or the main cake, depending on who you are, is that Kubernetes application development is a very exciting area of technology where there’s a lot of interest. I’m sure many of you are already doing that or thinking about doing that, and so this project should be useful to many folks.

I know James has a lot of ideas of what he can do on Jenkins X, and I also fundamentally believe that a lot of good ideas also come from outside. So please help James and his team build a better software by participating in the effort. If you don't feel like you don't have any specific point to make, even just providing them an encouragement would help them feel good to press forward in the current direction. That's an useful feedback on its own.

I hope we’ll see a very lively discussion.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/1500b5bd-d320-4551-aa5c-3f2036ea6403%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Kohsuke Kawaguchi

[James Strachan]

Thanks for those kind words Kohsuke. More inline...

On Thursday, March 15, 2018 at 2:32:48 AM UTC, Kohsuke Kawaguchi wrote:

Thanks James,

This is an important and exciting JEP for me, because it sets the mission & scope for a new project “Jenkins X.”

Starting from Jenkins 2, in contributor events and Jenkins Worlds, I’ve always pitched that our Jenkins project needs to take a bigger role and responsibility in serving our users and solving their challenges. Historically, by and large we did it by writing plugins, but we’ve been so successful in doing that, now we need to create solutions that combine those plugins.

I said “starting from Jenkins 2” because the default recommended set of plugins, initial setup wizard to start Jenkins more securely, and so on was the first step toward us doing more than writing plugins.

Blue Ocean followed, in which we focused on important parts of Jenkins and provided great UX for that. It decidedly blended together feature areas that are internally provided by a whole bunch of different plugins, but users see much less seam between them now.

Jenkins Essentials, which Tyler posted in recent weeks, is one more step forward. That project is aiming to take an even bigger responsibility in keeping people’s Jenkins instances up and running, and further de-emphasize individuality of plugins and emphasize the combined solution.

I see Jenkins X very much on this same path. Jenkins X brings a different aspect to building a solution — it focuses on a specific vertical area, a Kubernetes application development, and really drastically simplify the software development by bringing together Jenkins, a whole bunch of plugins, the opinionated best practice of how you should use Kubernetes.

Especially early in the days of Jenkins, this kind of integration was done by heroic Jenkins admins and provided for the organizations they were working in, but they were never really shared upstream in the community. So we all had to re-invent that.

Jenkins X is a significant step because it is trying to bring those hard-earned integration work back into the community. It makes Jenkins approachable and valuable to a whole new set of users who are not currently using Jenkins.

From that perspective, I hope more projects like this will follow, in different domains of software development. This is a little bit like how Eclipse has evolved from just a Java IDE to an umbrella of projects.

On top of all that, the icing on the cake, or the main cake, depending on who you are, is that Kubernetes application development is a very exciting area of technology where there’s a lot of interest. I’m sure many of you are already doing that or thinking about doing that, and so this project should be useful to many folks.

For me, one of the most rewarding things about Open Source is being able to learn from others in the community whether via code, docs, demos, email, issues or chat. A lot of things have changed in our industry in the last few years around containers, Kubernetes, cloud, DevOps & CI/CD best practices. So I'm hoping that even if you are not yet ready to use Kubernetes in your day job or are not yet interested in automating your Continuous Delivery; that you'll at least consider taking a look at Jenkins X - if for no other reason than to help you learn more about all these new ideas, technologies and approaches. 

We'd love any feedback you might have. Pull Requests are always welcome too ;)

 

I know James has a lot of ideas of what he can do on Jenkins X, and I also fundamentally believe that a lot of good ideas also come from outside. So please help James and his team build a better software by participating in the effort. If you don't feel like you don't have any specific point to make, even just providing them an encouragement would help them feel good to press forward in the current direction. That's an useful feedback on its own.

I hope we’ll see a very lively discussion.

Agreed. I'll try get a blog post together soon introducing Jenkins X to try answer the question of why I think folks might be interested in taking it for a spin...

-- 

James 

[Michael Neale]

Nice description!

Given the disparate timezones of everyone involved, would it make sense to have a few office hour type things? (not sure if there is enough interest in APAC timezone, if there is, let me know.

[James Strachan]

sounds like a great idea! What kind of times would suit folks? 

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/d5b2101c-6d5d-47e5-8848-115728369ed5%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

James
-------
Twitter: @jstrachan
Email: james.s...@gmail.com

Blog: https://medium.com/@jstrachan/

CI / CD for kubernetes