Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Continuous Delivery Test

sourceless.org

Post reply on HN
Print view View original

41–50 of 72 posts

Re: The Continuous Delivery Test

#41

Post by wahnfrieden »

simongr3dal wrote: post #37
8n4vidtmkvmk wrote: post #31

Earlier quoted context omitted.

i work on a very large team and solo for my side hustle. love working solo, no red tape to fight. no waiting 24 to 48 hours for a teammate to review my code per iteration and up to 24 more for it to deploy. just signed 2 contractors on for my solo project though and its really messing up my process. all the overhead is so high I'm not even sure it's worth it even if they were free.

I like to imagine it as a sort of volume vs surface area problem. The amount of service you can deliver to costumers is your surface area, but the amount of work you put in only contributes to the volume. As the number of employees grow you will necessarily be less efficient, but there aren’t really any other great ways to gain the required surface area.

there are perhaps interesting options with bringing in partner-level labor instead of buying someone's time-in-seat and the relative personal investment involved in each

the big point glossed over is that wage labor, where the value they produce is taken from them, isn't a great incentive for great work. that's imo a far bigger issue than fundamental challenges with collaborating, and why so many managers need to continuously trick their employees into productivity

Re: The Continuous Delivery Test

#42

Post by kqr »

satyrnein wrote: post #32

I'd like to see a workflow that meets all the criteria. I was surprised to see the item about deploying directly from your own machine; that seems to contradict the other goals which point to automated pipelines that deploy on merge.

I feel like a lot of people misread that point. It's not about deploying to production (that sounds nuts!) It's about spinning up and deploying to a full dev environment. This is in part to not have to run everything locally, but mainly to exercise deploy automation regularly.

Re: The Continuous Delivery Test

#43

Post by xorcist »

KronisLV wrote: post #28
bhawks wrote: post #10

> 11. Do you include ticket IDs in your commits or branches? This is one of the things that sound 'good' on the surface and are totally worthless in practice (especially when practicing minimal commits). In the wild this devolves into a meaningless umbrella issue (Deliver Feature Foo) or 1 liner issues that sometimes did not even match the pr contents. Just use the commit message and in pr review enforce commit messa…

> This is one of the things that sound 'good' on the surface and are totally worthless in practice (especially when practicing minimal commits). 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 co…

> ABC-855 and ABC-1233, to understand the business context and historical limitations

This should be what a commit message is. Commit messages should describe the rationale behind the change.

Ticket numbers are great for linking commits together. But they should not have to be relied on to find out why a change was made. Ticketing systems may come and go but commit messages persist.

Re: The Continuous Delivery Test

#44

Post by KronisLV »

xorcist wrote: post #43
KronisLV wrote: post #28

Earlier quoted context omitted.

> This is one of the things that sound 'good' on the surface and are totally worthless in practice (especially when practicing minimal commits). 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 co…

> ABC-855 and ABC-1233, to understand the business context and historical limitations This should be what a commit message is. Commit messages should describe the rationale behind the change. Ticket numbers are great for linking commits together. But they should not have to be relied on to find out why a change was made. Ticketing systems may come and go but commit messages persist.

> Ticket numbers are great for linking commits together. But they should not have to be relied on to find out why a change was made.

In theory I agree. In practice, I've yet to see it work out that way - there are always discussions with clients/other departments in the ticketing system which will never appear in the commit messages. References to logs, screenshots/animations of the issue and other things that give the full context to why that change matters.

That's also why I believe that code alone is not enough - you need code comments to explain not what the code does, but why it does it that way etc., it's just that ticketing systems can provide even more of the surrounding information which also doesn't fit either in commit messages, or in code comments.

> Ticketing systems may come and go but commit messages persist.

I'd say that everything comes and goes, but in most cases you won't have to worry too much, since most information will be kept around in some capacity, like migrating SVN revision messages to Git commit messages (though even that wasn't always quite possible, in the case of non-standard repository layouts, since most migration scripts broke) etc.

Though with how deeply integrated some companies out there are with solutions like Jira, I doubt they'll ever rid themselves of it.

Re: The Continuous Delivery Test

#45

Post by choeger »

alkonaut wrote: post #9

Extremely web centric list. Any other development (mobile, desktop, games, embedded, …) will find a lot of these steps very weird.

Pretty much everyone with more than one production environment will. Imagine developing Firefox. How do you do a "self-healing deployment" automatically whenever trunk changes?

Re: The Continuous Delivery Test

#47

Post by xorcist »

UweSchmidt wrote: post #8

> 9. Does your Infrastructure as Code live alongside the service it hosts? That means minor changes to some test infrastructure have to go through the strict review process, because the gitlab-ci.yaml is in the part of the main code. Last time this happened to me I found it annoying, and I don't think the code quality guardians care about some CI config anyway.

I will be first in line to suggest to not split repos unless required. It is my experience that deployment, admin and node provisioning (and everything that is generally put under the not always useful IaaC umbrella term) is one of those exceptions. Often documentation is, too.

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.

Re: The Continuous Delivery Test

#48

Post by zaat »

choeger wrote: post #45
alkonaut wrote: post #9

Extremely web centric list. Any other development (mobile, desktop, games, embedded, …) will find a lot of these steps very weird.

Pretty much everyone with more than one production environment will. Imagine developing Firefox. How do you do a "self-healing deployment" automatically whenever trunk changes?

You take the standard course of action, sending the PR team to state how Firefox is there as a beacon of hope and aspirations to privacy.

Re: The Continuous Delivery Test

#49

Post by zaat »

9. Does your Infrastructure as Code live alongside the service it hosts?

No, the IaC is configuration, and configuration should be separated from the application.

in organizations that implemented GitOps, the IaC files in git are not only a copy of the configuration, it is the source of truth from which the configuration is copied to the systems. Unless all the developers who can commit code should have permission to change production configuration, the IaC repo should be separated from the code repo.

Re: The Continuous Delivery Test

#50

Post by ryanklee »

etamponi wrote: post #46

7. 7! This is by far the one that resonates with me the most. But for some reasons SREs think the opposite is true: the longest it takes to get to prod, the better. What a pain.

I'm an SRE and currently on a mission to get code into prod as fast and safely as possible. Instead of painting such a broad, generic negative picture, maybe articulate an actual position to argue against.
Post reply on HN