summary: Describe your release process in a concise way with proper abstractions with hooks to integrate with other tools. status: Post-1.0 code: planned
A toolkit for release management that allows you to describe your release process in a concise way with proper abstractions. Other tools in the ecosystem will be able to hook into that (e.g. by their REST API). For example we are working together with JFrog to use Artifactory as a repository/UI for the staged/released artifacts. We think this is one of the holy grails of the Java enterprise automation domain that is still waiting for a proper solution. We think the build tool should be the driver, but it must be able to integrate other tools of the ecosystem (Jenkins, Hudson, Nexus, Artifactory, Teamcity, …).
Some in the Continuous Delivery camp are recommending folks move away from Maven (and to Gradle in some cases - see ThoughtWorks Tech Radar). Some find Maven’s notion of SNAPSHOTS an anathema to CD (see https://techinations.wordpress.com/).
As for Gradle’s Release Management I’d sure like to see it support CD in a substantive way - namely by supporting immutable builds with automation around keeping a transitive tree of dependent artifacts all wired together without resorting to version ranging or unreliable and un-reproducable SNAPSHOT builds.
For us, this topic is the next big challenge. We totally agree with the following statement …
We think the build tool should be the driver, but it must be able to integrate other tools of the ecosystem (Jenkins, … , Artifactory, …).
As we probably cannot wait until this becomes available, I would like to have a better understanding on the Gradle approach to this in order to avoid building any off-track home grown solution around Gradle. Is there a specification one could read and contribute to?
Unfortunately we don’t have a design spec for this yet. There is some other ground work we need to do before we can come up with a really good solution here. It would be too early for us at the moment to specify the details for this.
I think I’ve got some good ideas on this topic. I’m currently creating a fully open-source so called “Continuous Integration” server. See the following links for details: - project: https://github.com/pvdissel/cy.io
I base alot of my ideas on how gradle works and constantly read through the gradle source for implementation ideas. I’m not an advanced gradle user (currently only using gradle in hobby projects), but I love the idea and implementation of gradle. The further I get with my implementation, the more functionality I see that I could reuse from gradle.
During DevOpsDays Amsterdam (http://devopsdays.org/events/2013-amsterdam/) this June, I want to throw my ideas and hopefully a working demo into the group in the form of a Ignite talk and a discussion in the open-spaces.
I would love to get in contact with the Gradle devs to talk about this further. Maybe my ideas can be combined with the gradle “release management” ideas into a second tool of gradleware, I would love to help working on this. Extending the automation of gradle to a next level.
As I’m reading through most of the gradle source, the whole picture of the gradle structure is getting clearer every day. But I could use some additional pointer as I think I often still miss the parts on how things are all working together.
i am working on a set of plugins to automatically configure a set of teamcity jobs from a gradle multi-project build.
My initial idea is for an every subproject of the root be a separate build job. The build server would then wire up these projects to automatically version projects and manage dependencies as they change. (On your dev machine is appears as a though you build everything from source).
I would want there to be tasks which automatically configure and maintain the jobs in the build server.
Have been involved in implementing something like this in the past using maven/python/java. Gradle seems like a good fit.