Hacker News new | ask | show | jobs
by CuriousSkeptic 2700 days ago
I’m considering migrating an appveyor setup to devops. The main driver is to get a pipeline setup with more parallelism and a more complex graph with resumable steps without fiddling with environment parameters, or really jumping around in a clunky ui maintaining a hundred “projects”

Haven’t looked to deeply what devops has to offer yet, but things I’d be looking for before migrating.

- I want to be able to develop, run and debug most, or all, of the steps in the graph on my development machine without roundtripping through long chains of triggers and pushing to code repos and pull requests

- I want to run as much as possible in parallel, preferably agnostic of wether it’s on the same machine or several

- I need to build and assemble many components from same repository (monorepo setup)

- only impacted components should build

- Sub-components may depend on different build tools (service fabric services with both webpack and msbuild based packages)

- Some steps may depend on configurations and secrets with a different lifecycle than the code branch being built

I imagine something clever could be built on docker to support both running things locally as well as customize build nodes.

I don’t care to much for scripting in yaml. In fact I spent the day converting some yaml (and cake) scripting to Invoke-Build. Invoke-Build is quite nice actually, the only thing I miss is the option to orchestrate tasks in parallel onto several build nodes. That plus something like ncrunch build/test engine for csharp projects

(really the entire vs/msbuild things needs to be replace with something truly distributed, incremental and repeatable)

1 comments

I can recommend https://concourse-ci.org/ for pipelines that are difficult to reason about or orchestrate in, e.g. GitLab and other CI tools, due to external actors or lifecycles beyond a single codebase/repo.

Builds are 100% stateless within the CI cluster and rely on tracking/publishing just about anything you can imagine or plug as a resource; out-of-the-box inclusions being docker images (registry), S3 (e.g. minio, AWS) and git.

It's a bit strange to reason about in the beginning but I have yet to try anything that comes remotely close to Concourse when it comes to orchestrating across multiple sources of input/output and non-linear pipelines.

Awesome, looks almost exactly to what I imagined building.

Thanks!

I forgot to mention the semver resource which is a bit weird to use for a single repo pipeline but comes in handy for out-of-band jobs like running an external automation test suite asynchronously.