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)
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)
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.
No source control, there's only 1 version of the software; the latest version (trunk based development).
> 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.
