👏 I 👏 Love 👏 Deployment 👏 Pipelines 👏
I really do!
I have a theoretical one I am quite happy with. It isn't in service, but I could implement it and it would not bring me any value. yet.
I am writing a new game engine. This is just to let me learn Vulkan before I hack apart my Rust game engine. This one is written in C++, and after struggling with CMake for FAR too long (3 days...) I'm finally actually coding.
Deployment pipelines for regular software are interesting in and of themself. Needing to orchestrate containers in a microservice architecture, or deploying a monolith to many servers; that's a hard problem! How do you make sure your product doesn't go down, how do you let any engineer deploy. I've worked on these systems and they are interested with complex edgecases. But for a game which you deploy an executible for, it's a interesting in a different way.
Games aren't like other software. Sure, you have your Excel and Word, but with games you have to package content. This is hard. You can't just ship PNGs and WAV files, that would be too slow for load times. You can't store 3d model information, because you'll have to transform it to a format the GPU likes at runtime. So you have to pre-process it.
This means your deployment pipeline forks. You have both code and assets, but both have to be linked and bundled together. If you have a build that passes tests, you should also have an asset bundle which can be linked to it; preferably the newest ones. But some branches may use assets which have been renamed or changed in some way. Linking assets to builds is necessary.
My theoretical pipeline did this. Upon pushing changes to a local build server, it would first split assets from code. Some assets are code, such as shaders, but in general you would rip your assets away and test the code independently. The code pipeline isn't anything novel, so I won't discuss it here. The assets get split, and immediately preprocessing begins. First would be a hash to check for the changes needed; git is no help here due to binary files. After hashing, if a UUID doesn't exist for the asset one would be generated. This is pushed to a database, and then the assets start getting bundled. 3d models would have their vertices shoved together, materials would be linked, and textures would be compressed. This is all done so that when we load the assets we don't have to do this at runtime.
Once code is built, the required assets are grabbed from the asset storage server and it's all packaged into a neat little zip file. The tested code is pushed to GitHub/GitLab, and a build is provided to anyone who can download it.
From here we could do stuff like autoamtic Steam releases and whatnot, but that is beyond what I know; I've never released a game commerically. But I think this pipeline would work. I hope to implement it one day, and if I do I'm sure I'll write about it.