Step Durations for Codeship Pro

Codeship News

Reading Time: 3 minutes

The time it takes for your build to execute is critical to your team’s efficiency. The faster your builds and tests run the faster you can deploy your code. The faster you get insights into if the recent changes are working. In the past we talked about how to optimize your build speed through improving your image caching and Dockerfile structure. One important piece of insight that you would need to properly analyze and optimize your build performance has been missing up until now. We are happy to announce that Codeship Pro now supports step durations, telling you exactly how long a step ran from start to finish.

Now that you can see how long each step of your pipelines takes, you can optimize the performance for each individual step in your overall build pipeline, improving build times and getting build feedback faster.

How are my steps performing?

So, how do we define how long a step is running or how long it takes a service to build? Step duration is the total time taken to execute the testing command in each step – from the time the step is dispatched until the step is finished and the results are processed.

“How are my steps performing” was a big question, and so far only accomplishable by work-arounds. Now we are able to show the duration of build steps and services, providing great insight on how each step is performing.

image00

Steps show a duration clock next to the status icon. The format is minutes:seconds. This is also possible for grouped steps, giving you even better insight on how to strategically organize your specs to run everything in the most efficient way.

Codeship Step Durations

Parallel Steps

Because running steps in parallel can make understanding the timing and efficiency of each thing happening a bit difficult, being able to see the step duration on each parallel step separately makes it incredibly easy to know if one parallel step is taking a lot more time than another – which means you can optimize how you group your steps or figure out which steps need to be made to run more efficiently!

Optimization

The best part of knowing how long your steps take is that you can do something about it. We’ve got a lot of resources focused on speeding up your builds, optimizing your image sizes, deploying Dockers apps and more. Reviewing these guides with your individual step durations in mind will make it easier than ever to see where you need to invest time into optimizations.

Caveats

Please note, that we are not able to provide this information for past builds before the release of this feature. In that case there will be no duration visible on the steps or services. Regarding services, the time can vary a lot depending on the build time. If a service is cached already, there will also be no duration visible.

Should it be interesting to see step durations of older build, just rerun that specific build by using our handy rerun button. Just be sure it’s not a build that ends up deploying production code.

Try Codeship Pro for free

If you haven’t yet, I’d like to invite you to give Codeship Pro a try. We offer 100 builds/month and unlimited private projects for free. If you’d like to learn more about Codeship Pro you can read more about it here.

Subscribe via Email

Over 60,000 people from companies like Netflix, Apple, Spotify and O'Reilly are reading our articles.
Subscribe to receive a weekly newsletter with articles around Continuous Integration, Docker, and software development best practices.



We promise that we won't spam you. You can unsubscribe any time.

Join the Discussion

Leave us some comments on what you think about this topic or if you like to add something.

  • Tim Hines

    This is great! Can we query these build times or act upon them? I’d like to do things like:

    – Fail the build if build time is > X
    – Report build times e.g. via a Slack bot (e.g. Warning build time is > X)

    Also, the metrics appear to be elapsed time. When CS is busy vs quiet, the build time moves. Is there a common metric (e.g. CPU time) that is better to compare?