Recent submissions

Comment · 5 years ago
"Students count pigs and play with some numbers"
Comment · 6 years ago
Ok thanks, that's more what I was after :)
Comment · 6 years ago
Yeah I get that much (Sorry should have said so) I am trying to understand the real-life context.
Comment · 6 years ago
What the hell is with that image in the intro, with the smiling waiter?
Comment · 7 years ago
Looks like an assemblage of raffle prizes on a table, first prize is the weird wig in the foreground.
Comment · 8 years ago
We "Feature branch." With a twist on some of the busier repositories. We have a repository per application. We use Subversion (VisualSVN the Windows port)

1. Branch current live revision from Release to branches/ticket-ref (Our Release is what others may call main, trunk or master)

2. Work on feature.

3. Code review.

4. Merge to Release, CI (Jenkins) picks up change and builds NuGet package(s) pushes them to Octopus Deploy

5. Deploy into Test environment

6. QA pass/reject

7. If reject go back to 2.

8. If pass Deploy to production (single click in Octopus Deploy)

9. The twist for busy repositories with lots of changes: Cherry-pick merge to a Stable branch, which CI builds and pushes to Octopus Deploy Live channel

10. Deploy to production

Biggest issue we have is concurrent features x y z all being worked on, x y z are all deployed in test environment, y is passed by QA but can't be deployed because that versioned package also contains x which is rejected, so has to wait until x is fixed, which will then of course contain z. This is only really a problem when we want to get an emergency hotfix w into production. Right now we have to revert x y z from the Release branch, merge w build and deploy then put x y z back in.

This has taken 2 years to perfect so far. Changes we are considering:

a) Jenkins plugin that automatically creates a build configuration the moment you create a feature branch in SVN, this way we can keep x y z in separate versioned packages (I personally feel this is not true "integration" because you are keeping things separate.

b) Feature switches. So if y is good but x and z are not ready we just deploy with those features switched off.

We deploy on Tuesday/Wednesday/Thursday most weeks, never Friday - Monday.

Comment · 10 years ago
unknown NOT underground it's on a hill ffs
Comment · 10 years ago
tl;dr Blame the tools.
Comment · 10 years ago
Comment · 10 years ago
fud
Comment · 10 years ago
This thread. Thank you, and bless you. Made my day :)
Comment · 10 years ago
WiKi

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton