Master only. When you push to master it goes through the tests and then deploys to CI, tests in place on CI, and pushes to prod. You can optionally disable auto-deploy to prod if you have something you want to try some manual tests on before pushing to prod. I mostly do this for one-off perf testing.

If you have a long running branch, you should merge from master frequently so that your merge back won't be so hard

anyone have a good book recommendation for:

I want to build some simple SAAS in my office and then get salesman to go around and sell it? I'm not looking for "the keys to a billion dollar start up"... more like "How we grew our business into having 10 employees".

crazy your company doesnt have that stuff whitelisted.

blacklab, its actually even crazier they don't let you have good monitoring (or I guess "observability" is the term the cool kids are using now) tools if a big part of your purpose is testing stuff out and seeing how it works.

Also, I love how your background is good enough to work around this whole security setup they've got going. It's like TSA level protection!

The two most recent approaches I've used:

1. Master is prod. Anything merged to master is going to be released soon. All work is done on feature branches. Have a dedicated integration branch that the test environment runs off of (so anything merged to that branch gets pushed to the test environment soon).

I like this for frequent and fast deploys. It scales fairly well since all developers can control the code they're releasing (you're just merging your feature branch).

The one big downside is that your test branch needs to be managed. We regularly re-branch the test branch from prod - but every time you do that developers have to re-merge the feature branches they were testing there. It can also cause some problems where you have things that live outside of the code being used (although this generally helps you minimize that and push stuff to code). So there's a tension between re-branching often and staying really close to prod but making it more work to work-on/test long-lived features.


2. Master is the test environment. Releasing means promoting a build from the test environment to the production environment.

This works relatively well for small teams or certain types of software. It's nice that a release to Production is always an exact copy of something that was in test - so there are no surprises like where it turns out your feature was relying on something in test that isn't in production yet.

The main drawback here (which is big) is that releases are gated on everybody being ready to go to Production. So all it takes is one long-running feature to make it hard to release everything else.

--

In an older life I did the release branch thing and it was a giant pain in the ass. Although its hard to separate out the pain in the ass of the branching strategy from the general pain in the ass of only releasing every month/quarter and having to maintain a release-ready copy of the code while still doing new development for future releases.

My last job had a test/deploy system that I really kind of liked, that I have never been able to convince anyone to use. Granted, it's a little weird.

They used jenkins as the build/test system. You do everything in a branch. When you push the branch it makes a build job in jenkins that builds and tests your branch. If your branch passes, then you can click a checkbox that says "release to CI"

The way CI works is that it checks out the current master (prod) branch, and then merges all the branches that have their "release to CI box" checked, and runs the integration tests.

The beauty of this is that
* you can test 2 branches at a time, which is nice if you and a coworker are working on a solution that has some interaction
* you can easily "remove" your branch from CI if there's a problem or you want to work on it more
* CI is automatically up-to-date with prod

If the integration tests pass, any branch that was in the test can have a button pressed that merges it to master, and it'll be in the next deploy

Serious question - let's say I commit a bunch of stuff to my local branch and push to my remote branch. Oopps messed up.

So now I basically just want to completely undo that action. I want my remote and local branch rolled back, and all my changes sitting back on my local machine in uncommitted form. I don't want to lose my changes, just undo the commit and push.

I don't necessarily care about the history unless that will confuse git somehow further down the line (IE - I don't care about squashing commits for human readers or logs or anything).

Every time I try to do that it turns into a big mess.

Epic programming fail.

We do something sort-of similar with Gitlab. Basically you don't merge to test directly. You run a command that pushes the branch, kicks off a gitlab pipeline that does a bunch of tests/checks + verifies the branch can be merged and then if everything passes it gets deployed merged and deployed automatically.

Merging to production kicks off a build, and then once that build is done, anyone can actually release it.

There's a few more complications but it actually works relatively well in practice.

Edit: I just realized I misread your post a bit. Is there an actual place where your CI code is running for manual testing?

My first response to these types of things is to spend an hour trying different words and seeing what they filter / don't filter.

Yeah, anything check with release-to-CI will be available on a staging website. It's nice to be able to see how things look/feel or interact with other changes. Also you might want to let your designers look at it, or get signoff from marketing or your boss or who knows what.

We moved to feature flagging for a lot of that stuff though, i.e. just go ahead and release it to prod and turn it on briefly or just for certain people etc.

Haven't tried this myself but maybe you can use git diff to save a diff between the last two commits, revert the last commit then apply those changes locally to your repo with git apply.

somethign like..

Ah, gotcha. So basically if you have a long-lived development feature branch you would have it checked for release-to-ci and everytime a new CI build is made it would be included.

That does seem nice - its like a really good combination of my 1 and 2 above.

Edit: I guess though it still has the downside that you can't have a long lived feature be testable/useable in the CI environment but not go to production? Agreed that feature flags are a nice way of dealing with this.

Can you apply changes from an actual file or is that something you came up that would seemingly work?

Can’t you just undo the commits locally and then force push your branch?

There's another button you have to push for it to actually merge to master.

The process that happens on CI is just a "local merge", it checks out all the branches over master, but doesn't commit/merge them

It took a while for everyone to get used to FF but once you have it, you do not want to go back. If they're cheap enough you can keep them around for config - like the throttling system I use is based on feature flags so if I decide on a whim that I need to change the throttling rate for a url, or a class of users, or whatever, I can just do it immediately, no deploy.

Yeah, I just came up with this on the fly but I don't really understand your question. I'm piping the output from 'git diff' into an actual file that I call changes.diff.

Then I apply those changes with the 'git apply' command.

This is a pretty common pattern in unix. You use the diff command to create a diff between files, then use the patch command to apply those changes.

in VsCode there is a button for "undo last commit". or you can do a git reset --soft HEAD@{1} or a git reset --soft <commitId> (find this with a git log)

after you have uncommitted the previous commit. just push the branch up to the remote. force push with a -f.

seems pretty easy so I proly am misunderstanding. like I uncommit stuff all the time. usually to move it to a new branch with a git stash so I can combine my changes with someone elses and test out how stuff will work.

So I think I am discovering I have a talent for and enjoy writing/using/debugging scripts and doing system level stuff. I don’t think i have a knack for writing and designing software code.

What type of careers are heavy in this? Devops/sys admin type of stuff? What should I be focusing on learning ?

I was asking if you could apply changes directly from a file. My much longer workflow would look something like...

this is a good question bc it makes me think about our process which I never do bc it really doesnt apply to me.

so we have a branch called develop which I guess could be considered master. And we have a bunch of teams working on different features and we all pull and push to develop. When we decide to do a release to production, we will cut a branch off of develop and call it the release branch. we then test that branch for like a month in all kinds of ways. the problem is that we also will push some changes and small features/enhancements/bug fixes to that branch. sometimes even a lot. And at the end of the month, after we push it to production, we gotta merge the release branch back into develop this has caused bugs and broken features a few times. and in the mean time there has been a ton of changes to develop.

Thanks I'll check out some of those git strategies. Undo last commit is what I want - but it's not that simple I've found. I always try SourceTree reverse commit and revert commit and neither do exactly what I want. Then I get in trouble and almost lose my changes.

As far as our gitflow - basically master always represents what's in prod. We don't merge to master until after we put a release branch in prod and we're completely happy with it - like days later.

We may have lots of long-lived feature branches and a few long-lived release branches in development at any time. It's the responsibility of leads to constantly pull in master and
possibly other relevant branches that are scheduled to go into production prior to the one their working on.

Devs have their development branch(es) and it's their responsibility to always pull in the feature or release branch they're working on. Dev branch names are of this form: dev-suzzer-release-012209, dev-suzzer-supercoolnewfeature, dev-suzzer-bugfix10777, etc. This allows us to periodically prune old orphaned branches that start with "dev-".

Note this is monster website with a lot of manual smoke-testing and deploy steps. So YMMV.

One nice thing about release branches is if we found out something broke like 2 weeks after the release, I can do a dummy pull request (DMN- = DO NOT MERGE) between the previous release and the current one and scan over the diff for possible culprits. I guess you can do this with tags (which we hardly used but probably should have). But I really like the visual onsite diff of pull-requests, and ability to add comments, etc. Maybe I can still get that with tags?

sorry, i can't really tell you if that would work without doing some testing myself. I was just theorizing with my earlier suggestion.

Question for web developers: in production environments, is it standard for you guys to use package managers (npm, yarn, whatever) that download remote code for you, that you guys depend on in your code?

I ask because, multiple times this year (most recently today), another engineer at our company has discovered for the first time how Go's dependency management/package importing works and started freaking out on Slack about it. It is a terribly dumb system, and requires hardcoding the URL for dependencies, like so:

Then when you build your code, Go's tools will go download that repo for you. I built a slightly better system on top of this where we actually version the dependencies by commit.

Anyway, this other engineer is freaking out because we depend on remote Github repositories that are not controlled by our organization. This is how our server team (working in Go) has always done things, but it's new for our application team that's used to working in C++.

My reaction is basically "this is how the entire web/Go worlds do things and the world hasn't exploded yet" (apart from that one time leftpad happened), but I figured I should make sure that this is, in fact, how the entire web world works. He's freaking out because what if someone deletes the repository?! (we have dozens of engineers with copies of it on their hard drive who can push it to our organization in the incredibly unlikely event that happens)

I don’t know about the Web world, but we were doing that for one repo that got deleted, and my boss couldn’t find a copy of it anywhere but managed to find it in a repo that was controlled by Sears (lmao). So we just copied it over to our own.