- how would you create new builds?
- what do you expect to be required to do to create a dev, stage, prod deployment, and how to set it up?
- what would you pay for a solution like the one you imagine?
- would you reward if the solution wouldn't lock you to it, to a specific cloud or anything at all?
If you're a professional Devops/fullstack engineer, please try to look at it like you're "just" an application engineer ... so you're not into terraform, ansible etc.
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.
- 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.