Continuous Deployment/Delivery

Question

I read a lot about Continuous Deployment and Continuous Delivery but still i can't fully understand how to use it PROPERLY.
(I mean, i can throw up some line of bash and there you go. But i am not sure it's the correct way to do it).

So this is the question: What are your tools, implementations and logic? How do you implement Continuous Deployment? How you ensure everything you sent in production actually works without the unit testing (i am not allowed to do them.. I know..)?

Let's assume we have a project written in angular 8 and one in ASP.NET Framework and you have to integrate Continuous Deployment and Delivery to an IIS server. Which tools you are going to use and why?

I Saw TeamCity, Jenkins, Gitlab CI/CD, Azure, etc.. But none of them seem to be the correct choice to me (maybe because my Continuous Deployment/Delivery commands/business logic were poor).

Now let's assume you have to update the database as well. You can use sqlpackage and a dacpac to do it. Yeah but let's assume you have already deployed the "server" app in the previous step and the database didn't updated because there are some troubles with schemas. How do you behave?

Sorry for the very LONG post and those (stupid maybe?) questions, but i am trying to learn how to use it properly and unfortunately i am the only dev in my corporation..

Answer 1

There's a lot to unpack here. Continuous Deployment and Delivery are beefy subject themselves, in addition to the individual narrative.

It might be helpful to think about it by pulling apart software delivery practices (CI/CD) from its implementations (Jenkins, TeamCity, etc) and tools (server, database, framework, etc). At least three separate types of beasts to make sense of.

CI/CD exists to help business mitigate risk and learn from customers as fast as possible by constantly and iteratively putting software on user's hands. CI/CD has been so successful that a company would highly benefit if their engineers leverage existing services that implement these practices as much as possible.

Jenkins/TeamCity, AWS/DigitalOcean, and all these other types of services know what they're doing so you can more of less "simply" hand your code to them - assuming everything is properly setup - and they'll pull the code, run tests (if exists hopefully, otherwise what's the point), build the project and ship it to production. This can work for "rich" or "poor", big or small, complex or simple type of application, it really is agnostic to the project's perceived state.

So going with a simplest option and jumping through the hoops to get everything setup is one step to take. To start quickly, sometimes the less one knows about the nitty gritty details of everything and the smaller the steps to take, the better it could be; so setting up a CI/CD sample pipeline with a "Hello World" type of application and a dummy unit test (because why not) is a good confidence boost and can help clarify some miunderstanding of that piece of the puzzle.

Then once that's out of the way, playing with specific tools, framework of choice, favorite technology and whatnot becomes another part of the problem to tackle.