Workflows seem like they will potentially help us. 1.0 doesn’t really have a notion of a “build” step, which is fine for our Python code but kind of awkward for Java. Being able to define a set of steps with dependencies will let us get rid of some less-than-beautiful test runner scripting.
Related to that, the ability to more precisely control caching behavior seems useful. Because we kind of have to simulate a multi-stage build/test workflow in scripts right now, we end up throwing away some dependencies/artifacts that could be cached between commits.
The other big one is manual approvals. I don’t know enough about the feature to know if it’ll do this, but my hope is that we’ll be able to use it to do our production releases from CircleCI: tag a release, wait for it to hit our staging environment, then once any manual testing is finished, hit the “approve” button and it goes to the “deploy to production” workflow step.
Less important in the short term, but possibly still something we’d play with, is parallel workflow steps. 1.0’s parallel test features don’t help much for us because we end up having to build the code on each of the test systems, but if we can separate the build step from the test-running step using workflows, there’ll be a bigger performance gain from parallelizing the tests.