
Ask HN: What would your dream CI/CD pipeline tool be like? - chupa-chups
If you could wish for whatever you wanted, what would your perfect CI&#x2F;CD tool be like?<p>- how would you create new builds?<p>- what do you expect to be required to do to create a dev, stage, prod deployment, and how to set it up?<p>- what would you pay for a solution like the one you imagine?<p>- would you reward if the solution wouldn&#x27;t lock you to it, to a specific cloud or anything at all?<p>If you&#x27;re a professional Devops&#x2F;fullstack engineer, please try to look at it like you&#x27;re &quot;just&quot; an application engineer ... so you&#x27;re not into terraform, ansible etc.
======
karmakaze
Push to a git repo which contains a dotfile indicating that CI/CD should act
on it. Possibly from subdirectories if it has multiple artifacts or is in a
monorepo.

Understands how to fetch/publish packages for common ecosystems (e.g. gems,
jars, npm, go) and extensible to add others.

Define multiple environments with selectable automatic/manual progression to
next environment upon passing test suite. Secrets can come from a separate
repo with more restricted access. Each test/deploy should include the code and
secret repo verion hashes.

Fast, parallel execution of tests in suite. Automatic retry of failed test,
metrics collected to identify flakey code/tests.

Perform blue/gree deploys in each environment. Audible text-to-speech
notification of test failures delivered to individual dev or group (via Slack
and/or other means).

Quick one-button revert to an earlier version in any environment. Historical
record of which version is running in every environment. Also have a button to
force-promote a failed stage onto the next.

Periodic health checks running a subset of test suite with dashboard, alerts,
and history. Audible text-to-speech announcement of health-check failures to
dev/group.

It should deploy and test artifacts in the cloud of my choosing, in the
deployment unit of my choosing (EC2, EKS, etc) to my own AWS (or GCP) account.

------
hitsurume
The developers I work with that are in other teams have figured out how to do
CI/CD with the provided tools that come with AWS and GCP. Throw in Gitlab and
Github doing their own CI/CD integrations, I don't know if there's a niche
left for you to go after. As a DevOps person, CI/CD is not rocket science, its
pretty straightforward concept that doesn't take long to set up and works
automatically afterwards.

------
druidgreeneyes
\- treat steps of the process as functions that return data, instead of jobs
that return at most success/fail, then provide me with ways to harness,
manipulate, track, and display that data. (And a documented structure by which
I can define what data I choose to return from a given step; I'm thinking
mostly about two scenarios, the first being metrics about a build, and the
second being structured information about errors/stacktraces)

\- provide me a way to use your tool locally during development, in place of
(or wrapped around) the standard build tool for my language, and a guarantee
that (within reason) it will give the same results on my machine as it does
when running an automated job managed by the server. Give me clean, detailed
ways to inspect the difference in situations where the behavior differs
between my machine and the server. This would in theory help me to reduce the
incidence of "works on my machine" sorts of errors.

\- Give me a a well-documented http/s api, and a way to add arbitrary
endpoints to that api, which trigger arbitrary scripts/jobs (or just query
arbitrary subsets of data from my first point above). I should be able to
decide whether my new endpoint is specific to some arbitrary grouping defined
for my org (and thus only visible to members of that grouping) or available to
anybody who can reach the endpoint. (I'm thinking of teams practicing radical
transparency, who might want to, say, provide a public endpoint that anybody
can hit that provides various build metrics; or teams who want to provide
their product owners or business stakeholders a controlled window into parts
of the process, without having to build their own services to provide the api
for that window)

\- give me an easy way to wrap a debugger around a given job or step, locally
or remotely, and a clean interface for stepping through it and (if
appropriate) walking the stack.

\- save a run as an artifact, so that it can be marked, saved, exported,
reviewed, downloaded, and stepped through safely at a later date and on a
different machine. I should be able to see responses that we got from remote
resources without having to touch those resources when reviewing a job saved
in this manner.

------
znpy
Heroku, free as in free software, self hosted.

~~~
raihansaputra
There's Dokku for single-server and Flynn for more flexible, multi-server
setup. I'm curious for other options.

I wish there's an easy way to have Netlify style preview deploys for all
branches with none of the hassle.

~~~
interactivecode
in my experience dokku is slightly broken en shitty compared to heroku. so i
guess you get what you pay for.

~~~
raihansaputra
can you elaborate on what's broken?

------
ianceicys
www.harness.io is awesome, definitely willing to pay for that. Also loving
Azure DevOps Pipelines.

