Correct way of Deploying to production using CI/CD server
Hi IH,
I have been working with software/web development for a while but the release procedure I've been doing has been fairly manual where I build locally and then SFTP the output to the production servers (this is both my full time job way of doing it and my side project). Although this has worked it is a bit of a pain, so I'm looking at ways of automating it using a CI/CD server.
I've been using TeamCity for a while, although not really for releases, more of just a way to test builds and dependencies automatically but would still just copy the build output and SFTP to a server.
I am using GitHub for the source control, and what I've seen that normally everything in the master/main branch is what gets auto published to production. This is the opposite of what I'd learnt and done previously as the main/master was the active dev branch for quick fixes, any major changes or feature requests would be branched from main/master and then once complete pulled back to the master, and then the master is tagged, and then the tag is what goes to production, but from what I've seen, tags aren't really used that often, other than to have a snapshot of what the master/main branch was at a given time. Is this understanding correct or have I missed something.
If this is correct, is there a generic guide someone can point me in, how do I get my production servers to automatically fetch the master when the CI/CD server runs its tests and build how would I get the build output pushed to production. I work with projects such as ReactJS, Laravel and C# .Net Core if that makes any difference.
I guess from what I've read, I could have main/master which gets pushed to production, a staging branch which gets auto pushed to my staging environment and a dev branch for local development and then when a feature branch is pushed to staging, the CI/CD server would auto push the build output to the staging environment and the same for when main/master pulls from staging but not sure how this automatic push to the different environments are done.
Any suggestions or links that might help would be greatly appreciated.
Thanks
Chris
In term of git workflow my go to is usually the "trunk based" approach. you can read more about it here https://trunkbaseddevelopment.com/
As it was said by another person, CI/CD can be as complexe as you want. If you are already using github, I recommend you take a good look at github actions. They are super easy to use and you can make almost everything with them lately.
To finish : Do you really need CD for a side project ? Can't a nice Makefile do the trick ?
Thanks for your input. I have been thinking of using GitHub Actions instead of TeamCity as it would mean I have one less server to look after/maintain.
I'm not sure I get the last bit though, admittidely I am very new to CI/CD server, so not sure what you mean about whether I need a CD for a side project, don't CI and CD go hand in hand. My main aim initially, is nothing too complex, just a way of automated testing and automated releasing just to make things a little simpler and less prone to going wrong with manual work. Although its a side project, it does have a paying customer so want to minimise the risk of manual processes.
I meant you could just focus on the testing part of CI/CD and have a a script in a Makefile to make the releasing part more straight forward. The deployment would not be automatic yet but super simple.
It's usually a good intermediate step for CD.
I hope i'm being more clear
Ah I see what you mean. Thanks for the help.
CI/CD can be as complex as you want to it to be, so this is a bit hard to answer because it you only want to create as much overhead as is useful for your project (through faster releases, automated testing/ re-rolls to previous versions, whatever you're aiming for).
If you're running .NET Core in the backend, it'd be natural to look at Azure DevOps, which I've been using in some projects on my past jobs. I think you already have a good understanding of the key terms, but maybe as a refresher take a look at this: https://docs.microsoft.com/en-us/azure/devops/pipelines/get-started/key-pipelines-concepts?view=azure-devops
Triggers can be everything you want them to be, but generally I'd suggest pull requests on the main branch. So you'd develop locally, check in regularly on your feature branch, and then merge it/ do a PR on the main branch of your repo (which could also sit in Azure DevOps but GitHub etc. should work as well). This triggers your Azure Pipeline, which can run trough several stages and even target several environments one after the other (like staging and prod).
So you could do automatic deploys from your main branch to your staging environment (and run tests/build artifacts etc.) and then do some sort of manual approval before it gets deployed to prod. Usually you get an email once staging is deployed and then you can manually test yourself and check a checkbox to deploy to prod whenever you feel ready.
Here's an example from their Learn sections, there's also the docs and lots of tutorials out there: https://docs.microsoft.com/en-us/learn/modules/create-multi-stage-pipeline/
Note that there is a visual editor for Pipelines (I think it's called Classic) but Microsoft is pushing hard for yaml to take over so I'd say that's the "modern" way to write pipelines in DevOps.
Hope that helps, feel free to ask more questions if there's things to clarify. I'm not sure how much GitHub Actions and Azure DevOps have been intertwined since the Microsoft acquisition, so maybe there's interesting new options nowadays as well.
That's great thanks for the help. I'll checkout those couple of links you provided. I don't necessarily have a .Net Core backend though I have various projects which are bit of a mix, some are .Net Core console apps hosting an API, some are Laravel PHP APIs and then frontend such as NextJS and ReactJS so looking for something as general as possible that can cope with different technologies, don't know much about Azure so not sure if there are limitiations to what it can do project technology wise.