Solo.

1) CI/CD

Gitlab self hosted.

Just plain .gitlab-ci.yml pipeline files & runners running on > 3 pc's (docker and powershell tags)

Basically using dotnet deploy with publishprofiles and environment variables.

3 parts: - Backend ( multitenant) - BackendGateway ( multitenant) - Frontend ( single tenant)

https://imgur.com/a/NW8bD4W

Deployment time: < 5 minutes ( staging and prod, including smoke tests)

2) Logging Axiom. Cloud.

Cheap to use for my project, i can stay on the free plan while I scale up.

Most of the mid to large companies I know of uses pipeline and registry of gitlab or github and deploy to kubernetes.

For k8s using gitlab, control bare and vms via puppet, (setting up ceph, k8s, pg clusters..)... using argocd for the k8s stuff.

Currently moving multiple teams from Jenkins to GitLab and transferring ownership of their pipelines to the teams themselves.

Vast majority of colleagues have no clue how to build & deploy their own code due to a very traditional siloed organisation (Ops people owned pipelines) - which is proving somewhat challenging!

We provide plenty of well designed pipelines in documentation to _hopefully_ inspire good practices... but time will tell...

So far it's all been Linux/Containers however we do have a handful of iOS and Windows projects to migrate in the pipeline (no pun intended)

here's one way of roughly doing CI & D

> 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.

For my side projects I just use a deploy script that uses ssh and rsync to move data, run migrations, etc to push from my dev environment to whatever production server I pass in as an argument. Nothing fancy but dead simple with easy rollbacks and a few hundred ms downtime.

Develop live on production (CI/CD).

No source control, there's only 1 version of the software; the latest version (trunk based development).