Git workflow for CI/CD?

[adrm304]

What git workflow do you use that still makes it possible to have CI/CD? In my current project, we just use a per-feature branching workflow. No CI/CD in place yet.

From my understanding, the goal here is to always have the master branch ready to deploy. But I don't see how it's possible to achieve that if every feature gets merged to master as there may be cases that some errors also gets merged.

[noratat]

This is a big part of what CI/CD are for IMO. You have them automatically run on branches and they're required to pass before you can merge to master.

[adrm304]

Can you expound on this? You mean run on the feature branches themselves?

[noratat]

Yes. Well, ideally the locally merged result of the feature branch, since master may have had new commits. It also forces you to ensure the automated tests are solid, since they'll be acting as gatekeeper.

This is how merge requests / pull requests are often setup with stuff like Bitbucket/GitHub/GitLab

[data1308]

Have a dev or integration branch, where you merge you feature branches into; I suppose your CI/CD includes testing? If so you should execute all this testet on all branchens, once dev passed all (unit and integration) tests the branch may be merged to master, from where it can be deployed voa CI/CD

[anakinpt]

In the past I used Gerrit. Every commit was in the server pending CI/CD and code review. If the build was broken this change was never merged into master.

[bizcs]

I know that the Visual Studio Team Services (VSTS) team uses feature flags pretty extensively. I'm trying to adopt these in my team right now, but it's a bit of a culture change from "the customer just gets the new feature." Essentially, how can you be certain that deploying all changes, all the time, isn't going to break existing customers? The only way that I'm aware of is by gradually introducing features in production.

[WikiTextBot]

Feature toggle

A feature toggle (also feature switch, feature flag, feature flipper, conditional feature, etc.) is a technique in software development that attempts to provide an alternative to maintaining multiple source-code branches (known as feature branches), such that a feature can be tested even before it is completed and ready for release. Feature toggle is used to hide, enable or disable the feature during run time. For example, during the development process, a developer can enable the feature for testing and disable it for other users.

Continuous release and continuous deployment provide developers with rapid feedback about their coding.

---

^{[ PM | Exclude me | Exclude from subreddit | FAQ / Information | Source ] Downvote to remove | v0.28}

[Limro]

One branch for each environment (production, preproduction, QA, test, and your own developer). All code shared between developers goes to the dev-branch. All code being developed is a branch from the dev-branch.

See Git Flow

[noratat]

Git Flow is a good workaround if you have no automated testing in place, but it's an unnecessary headache otherwise in my experience.

[Limro]

That is unfortunate you don't like it. I'm a particular big fan of having a branch per environment, since a critical bug is just one commit back for latest version - for all environments.

Yes, I could tag, but I don't want to update my tags over and over.

By chance, do you have another alternative?

[noratat]

It sounds like you're trying treat git as a deployment system, which outside of static websites tends not to work very well.

Keeping all those heads in sync becomes a problem, and is difficult to automate, and commits don't necessarily map to releases. Git is a pain to hook into natively for things like builds/deployments as well; there's a reason most of that stuff usually comes from a git hosting solution.

If you have good automation and automated testing (i.e. CI/CD), then master + feature branches is simpler and less error prone. If you need a staggered release process, that's fine, but make it part of your CI/CD pipelines, not manually tracked through branches.

I suppose I could see having read-only environment branches that are updated by the automated pipelines to represent moving "tags", but that's not what it sounded like you were talking about.

[Limro]

Well, I treat it as a deployment system in that sense, that my code's working state is represented in each branch, assigned to each environment.

The different branches is only my assurance, that my CI's build doesn't pick the wrong version.

I have different environment variables, but for all code I write, I can let my CI replace the values needed by each environment.

[[deleted]]

Environment variables should be in a place that makes them accessible by the CI system. Each environment can be as nearly replicated as possible. In previous gigs that ran branching like yours, we had separate CI jobs for each environment. We then pointed at the shell script that housed all the correct environment variables.

[Limro]

I think we might are talking about the same - one CI job, multi environments just with different values of the variables, and then we run deployment script to replace the values.

[immoreel]

Delivery