Full stack web dev.
Studying FP web development approaches, while helping Mission Bit create paths to programming for underserved public school kids.
Previously @ Gradescope.
CI refers to merging code continuously, and CD refers to deploying the app continuously. Doing both is increasingly common for SaaS apps. The tooling around this stuff is good now, but that wasn't always the case.
Regarding CI: I used subversion before I used git, and while it was just for personal stuff, I can't imagine that branching & merging with the frequency that's normal for git would have been pretty.
Regarding CD: if building the app takes a lot of manual work (as opposed to checking that the tests passed and hitting a button), it's hard to do it continuously. For hosted apps, we now have good tools for automating server provisioning (ansible, chef, etc.), and the hardware can be done in a virtualized way thanks to the PaaS providers. And tools like terraform let you automate it.
Some places still do "named" releases -- i.e. new code get written, then there's a feature freeze, the focus switches to quality control, and eventually a new version is cut. For certain products, like an OS, that's probably a better model. (In general, software that's installed by the end user follows a traditional release cycle, but there are exceptions, like Arch Linux's rolling releases.)
Some hosted apps still release that way. I imagine that one factor that might keep you on that model is if your app is itself a platform. When you're providing an API to your customers, they need a clear way of tracking changes and targeting a specific version. (Which is not to say that providing a versioned API forces you into a particular release style, or that app releases always line up with the API versions, or that such apps always do monolithic releases, etc., etc.)
Anyway, my point is that you can still automate merging and building when doing less frequent releases, but continuously releasing requires automation, and that is where CI/CD comes in. Note that the automation isn't an either/or thing. For example, deploying from a "special" machine is less automated than deploying from a server that can be rebuilt at any time from an image or script, but you can still deploy continuously, provided that the machine doesn't go down.
CI refers to merging code continuously, and CD refers to deploying the app continuously. Doing both is increasingly common for SaaS apps. The tooling around this stuff is good now, but that wasn't always the case.
Regarding CI: I used subversion before I used git, and while it was just for personal stuff, I can't imagine that branching & merging with the frequency that's normal for git would have been pretty.
Regarding CD: if building the app takes a lot of manual work (as opposed to checking that the tests passed and hitting a button), it's hard to do it continuously. For hosted apps, we now have good tools for automating server provisioning (ansible, chef, etc.), and the hardware can be done in a virtualized way thanks to the PaaS providers. And tools like terraform let you automate it.
Some places still do "named" releases -- i.e. new code get written, then there's a feature freeze, the focus switches to quality control, and eventually a new version is cut. For certain products, like an OS, that's probably a better model. (In general, software that's installed by the end user follows a traditional release cycle, but there are exceptions, like Arch Linux's rolling releases.)
Some hosted apps still release that way. I imagine that one factor that might keep you on that model is if your app is itself a platform. When you're providing an API to your customers, they need a clear way of tracking changes and targeting a specific version. (Which is not to say that providing a versioned API forces you into a particular release style, or that app releases always line up with the API versions, or that such apps always do monolithic releases, etc., etc.)
Anyway, my point is that you can still automate merging and building when doing less frequent releases, but continuously releasing requires automation, and that is where CI/CD comes in. Note that the automation isn't an either/or thing. For example, deploying from a "special" machine is less automated than deploying from a server that can be rebuilt at any time from an image or script, but you can still deploy continuously, provided that the machine doesn't go down.
Great Explaination Dev👍