1. Is your code source-controlled?

If not, get it into a code version-control system (VCS) yesterday!

1. Do you have different "Feature Branches" for new functionality?

If not, lock down your "default" branch (i.e. develop) and require Feature Branches moving forward.

1. Do you perform Pull Requests (i.e. move code from Feature Branch -> Develop after peer review)?

If not, start doing this (also yesterday!)

1. Does your code version-control system have "pipeline" capability?

If not, consider using one which does. If so, then consult the docs, enable it for "feature branch -> develop", and try automating the FTP step which puts new code into production.

A CI/CD (or "pipeline") is really a set of instructions or scripts (CI-specific, or something the CI supports like shell-script) which is triggered based on a specific set of circumstances (automatically when merging code from branch A to branch B, manually running a CI pipeline, automatically when running on a cron, etc).

Having said this ... generally speaking, whatever you can type manually in a terminal, can be captured in a script. And whatever can be captured in a script, can be automated in a CI pipeline.

Q1. Is CI / CD really seamless ?

It can be, but "seamless" comes from automating deployment through your scripts.

Q2. Can we do rollbacks to whatever was deployed ?

Ideally, you would have sufficient testing being run ahead of a deploy so that you can minimize rollbacks. But automating the steps you perform manually today, is key to getting CI automation working in that seamless fashion you're expecting.

Q3. How do we push from Dev / STG to PRD ?

Through steps built-in to your pipeline and branches. Read up on "A Successful Git Branching Model" for an in-depth discussion on one way to promote code using Git branching. (This is not the only mechanism, but this one is very well documented.)

An example CI pipeline for you might look like: - check out the code - install dependencies - run Unit Tests (Careful here -- Unit Tests shouldn't cross a boundary which requires external services... if your Unit Tests require a live database, they're Integration Tests. External services should be mocked for Unit Tests.) - package the code into a ZIP - FTP the ZIP over to your live server - remotely unzip the ZIP

What might really help you understand, is to create an example project which performs a minimal set of automated steps in a CI pipeline, and publishes something to a live website. A good intro is Gitlab Pages from Scratch; while the tools used are Gitlab-specific, the concepts learned here are transferrable to any CI system.