The Continuous Delivery Test (opens in new tab)

I worked for hardware manufacturers, for most of my career, and software was always just a "sidekick" to The Main Show. We just got the "Supporting Actor" nods.

I'd say that 90% of HN seems to be Web/SaaS (and, these days, crypto), which is an excellent workflow; just not the one I do. Nowadays, I have some integrated stuff, but it's mostly native iOS/TVOS/WatchOS/MacOS deliverables.

CD is nice, but I feel that CI is better, for a team. Even that, is overkill for the way I work. I'm spoiled, I tend to work alone, or very loosely-coupled. That gives me a different workflow from what many experience. I had to spend a couple of years "un-learning" a lot of stuff from my Big Team days.

The way I work results in astonishingly good stuff, very quickly, but the scope is much narrower than what a lot of folks here, do.

As such, I find little utility in telling others that the way they do things is wrong, and that they should be doing it my way. I do talk about how I do things, but I'm not judgmental about it.

I do feel that software quality, in general, is fairly problematic, but don't claim to have the silver bullet. I know what works for me, and I try to stay in my lane.

Essentially the only thing that's different with the types of development you mention is that "final deployment to production" looks different, as it usually involves more or less physically transporting artifacts to your customer.

But the rest is just the same. You should be doing trunk-based development, practise something like code review, gate on integration tests, feature flag, spin up virtual production clones, etc.

In other words, the fact that getting software to your end users is a clumsy process does not preclude you from doing every other step of the process with short feedback loops.

If you are in a regulated environment or selling to large enterprises you may find that having a SDLC policy of “no changes without ticket to track” is a more easily defensible control against unauthorized code changes (you’ll get asked about this in SOC2 and security questionnaires). The policy “anyone can make a change if they find a reviewer to approve” might not float.

Mandating ticket IDs can be really annoying though, for example if I want to make a few-line no-op refactor to clean up some code, I don’t want to have to create a ticket. So it’s definitely a tradeoff.

I feel like I disagree here.

Turning on Git Annotations in any JetBrains IDE and seeing who made changes, when and which Jira issue necessitated these changes right there is pretty useful. All of the sudden, you can easily say: "This method had been changed in 5 different commits in the last 3 years, what I probably need to read before making my own changes are issues ABC-123, ABC-236, ABC-455, ABC-855 and ABC-1233, to understand the business context and historical limitations behind all of this."

> Just use the commit message and in pr review enforce commit message norms.

I fully agree with this, but unless you squash your commits or rebase, finding out which MR/PR a particular set of changes belongs to isn't always immediately doable, especially when looking at things locally instead of the GitLab/GitHub UI.

Furthermore, the barrier of entry is higher: I always describe my changes and add a bit of context in the merge request/pull request description, sometimes even with GIFs or MP4 video demonstrations of what happens as a consequence of them. And yet, the majority of other developers have no desire to do that - I've regularly seen people leave those empty, and even commit messages are sometimes like: "try fix" instead of "make Ansible ensure that file permissions are set to have the newly created directory be readable by the group that will run the app".

In contrast, everyone is capable of adding a simple identifier to the issue management system and there are very few arguments that they can make against adding a few characters to the beginning, as opposed to: "But adding descriptions would take a lot of time and slow down development, I don't think we really need those because you should be able to read the code and understand everything."

Sure, you can enforce it in a top down manner, but it can be like pulling teeth at times, so you might as well ensure that at least the lowest common denominator is in place, before trying to find better approaches.

Exceptions to this might be small changes that don't really correspond to an issue, then you have two choices:

  - create an issue yourself so the work doesn't become untraceable in the issue management/billing system you use
  - just leave a short text description without issue identifier

You can check in git if work has actually begun, and you can get from and old commit to Jira by virtue of the merge commit.

I don’t know how you’d do it in a non-mono repo setting

That approach makes a lot of sense to me. Link the commit to the ticket when it enhances future reading, but not out of blind application of principle.

I have dealt with bugs that were thought to be fixed a long time ago, only for them to mysteriously pop up again later. Ticket is created and the old ticket is linked.

It's really helpful to see what was done 2 years ago, including the attempted fix that is now still live in the code base but apparently doesn't work properly.

That said, as always, it's not black or white. There are definitely cases where it doesn't make sense, but I don't think you should call it 'totally worthless'.

It all depends on what the release flow looks like. A useful rule of thumb when components can share a repository is when the branch model is identical. If that's the case for codified release and provisioning processes and the code that is shipped, then it is likely that you are not taking full advantage of what that deployment and provisioning code can do. If not anything else, then at least test versions must deploy production code, and test code deploy production versions.

Again, in my experience across multiple organizations, it is a good idea to keep that code both forwards and backwards compatible. It should be natural that is sometimes says things like "if build number greater than x then set parameter y". While it may feel a bit dirty for some, that type of logic is what deployment code does, and it is much more maintainable than keeping branches around for the same result.

If I get to say one thing to new devops/release engineer type people, that's probably it. That, and the value of clear and concise commit messages. Which goes double for this type of code.