Best practice for build pipeline visualization and gradle build steps slicing?


(strug) #1

Hi there,

how are you using build chain visualizations that CIs like TeamCity and Jenkins offer?

It seems as if I need to “drop” the built-in control flow of gradle in order to have a proper visualization.

Instead of one command ‘gradle check’ I have to “split” the automatic workflow of gradle and define different build steps like “unit testing”, “integration testing”, “functional testing”, … or would you slice more coarse-grained?

What is your best practice? How do you slice your steps?

Thanks, Leif


(Perryn Fowler) #2

Hi Leif,

That sounds like a very interesting question, but I’m not sure I quite understand what you mean. Could you explain further?

cheers Perryn


(strug) #3

Sure!

CI Server like TeamCity offer a visualization of different build steps. Here is a sample build chain.

The gradle documentation creates a static visualization of the build workflow. Here is the visualization of the jar plugin

If you have a gradle build script that creates a war and deploy that to a server all steps will be triggered automatically. If you want to visualize this you have to split that.

So instead of ‘gradle clean deploy’ you need to create multiple steps:

step1: gradle clean test step2: gradle integTest step3: gradle functionalTest step4: gradle deploy

For me it seems that there is no better option right now.

Maybe tools like TeamCity can create automatic visualizations based on the gradle model. That would be cool.

@Perryn I hope it is a bit clearer now:)

More details on TeamCity Build Chain can be found here


(Benjamin Muschko) #4

How you model your build pipeline with a CI servers is often times dependent on the requirements and needs of your project. I don’t think there’s a general rule. A good way to get started is to read the book Continuous Delivery. It outlines an exemplary build pipeline.

It’s generally a good idea to separate different types of tests. Run unit tests first as they’ll give you a fast feedback about broken test. In later steps, run integration and functional tests. Functional tests I’d probably run after deploying the application and target the deployment you performed in a previous step.

Each of the steps in a build pipeline I’d model with a job on your CI machine and then chain them together. This means that you call specific tasks of your Gradle build. The benefit of doing so is that you get dedicated steps. If any one of them fail, you kind of know what went wrong and can dig deeper. In between each of these steps, you can enforce quality measures, for example don’t move on with the build pipeline if test coverage is below 50%.


(strug) #5

Thanks Benjamin for your thoughts.

What I’m thinking of is that gradle could be used to model the hole pipeline. Nothing generic, specialized by developer needs. I can integrate quality gates like 50% test coverage and all that into my gradle build.

From the resulting gradle model I could create a visualization similar to the one CI server offer. I could display the “chain”, it could determine which “steps” are green/red.


(Benjamin Muschko) #6

You could probably write a plugin that provides a DSL targeted to model these kinds of things. That would certainly be possible.