> What tools and platforms are you using?
script the automated build process in something that is portable, agnostic of CI platform, and can be run locally on dev machines. E.g. a bunch of shell scripts and a makefile. Then define a minimal CI platform specific pipeline to checkout your repo then run the corresponding portable shell script or makefile recipe that actually does the work to build, test artefacts and push them somewhere.
by structuring things this way there's a fair chance that you can still get a hotfix build out the door if your CI platform is on fire, and also you dont have to rewrite everything each time you need to migrate back and forth between jenkins, github, gitlab, google cloud build, or this year's novelty platform vendor who impressed your leadership team
> How do you manage deploying to different environments?
have an environment config repo storing desired state of per env config in a bunch of sibling folders. have tip of main branch of this env config repo indicate the desired state of all environments. write a shell script to automate deployment that can be run manually from a dev machine
keep this environment config repo separate from the repo(s) which have the responsibility of maintaining and producing the deployable artifacts.
keep secrets in secret managers, out of version control.
if you wish, define a job in your CI platform that wraps this deploy script that can be manually triggered to deploy revision A of thing B to env C.
> How do you implement artifacts versioning?
if you have a CI platform that will maintain state of an incrementing integer build number, version artifacts with that build number
if you dont have that, version artifacts with the short sha hash of the commit
> context
team maintaining a backend service or three in a non tech enterprise megacorp, boring mature industry, for services consumed internally, not directly consumed by external customers
once you've got a rough process that works and you've been operating it for 6 months, it's more about identifying what your actual CI and deployment pain points are are (if any) and if they are worth solving, and seeing if there's something incremental and low risk you can do to improve the current situation given your current constraints. solve the problems you actually have (if any), not the problems you want to have.