[fedgiac]

Version v0.5.1 sneakily introduced a dedicated staging deployment.
The goal was to "make it work asap" and because of that it was never integrated into the process in this repository.
This already created a few issues when upgrading it, since the program address needs to be added to the actual deployed code, and skipping that causes at best a non-working contract, and at worse a critical security issue.

These changes officially introduces staging.

It's called barn here, to avoid confusion with other projects using staging to differentiate the mainnet and the testnet programs.

There are thee flows:

1. Standard deployment, uses the prod address.
2. Extra barn feature, uses the barn address (and could be eventually used to have different behavior in prod and staging, for example as a way to only introduce new code in staging before actually releasing it to prod).
3. Optional custom deployment address as a build env parameter.

Minor consideration

The weird syntax ${v:+"$v"} and the unquoted strings are used because MacOS uses an old bash version and empty arrays/variables are treated inconsistently.

The instruction suggest to merge, then deploy. This is risky if we merge new changes to the code between deployment and verification. Maybe we should suggest using actual merge commits and verify the release branch. But I didn't want to change that now since the project isn't expected to change so often now.

How to test

New unit tests.

Realistically, the instructions won't be properly tested until the next release.

You can still try to release a new program:

DEPLOYER_KEYFILE=...
solana config set --url devnet
PROGRAM_KEYFILE="../deploy-test-$(date -I).json"
solana-keygen new --no-bip39-passphrase -o "$PROGRAM_KEYFILE" 
just deploy-at "$PROGRAM_KEYFILE" "$DEPLOYER_KEYFILE"
PROGRAM_ID=$(solana address -k "$PROGRAM_KEYFILE")
solana program show "$PROGRAM_ID"

Expected:

• just deploy-at succeeds; notably it prints statePda at the end, sign that the program was successfully initialized (and so the program address was properly included in the code).
• The fresh program exists (the test isn't just using the existing deployment).

Example one-off deployment: J1bNPCX71a39SmQUstdR5MZhc5WsAaiL9VLh8fT1h3pk.

[linear-code]

SC-560

[kaze-cow]

my understanding is that we use "barn" terminology primarily on the frontend side to indicate a frontend release

So my major concern with using the terminology is that we use it inconsistently through the org, and at least "staging" seems to be more consistent. Its easier to understand that staging is deployed on the same production network than that "barn" is actually very similar to what most people would call "staging"

[fedgiac]

So my major concern with using the terminology is that we use it inconsistently through the org

Agreed.

and at least "staging" seems to be more consistent

Internally, staging has two meanings! I believe this is the testing frontend using the prod contract. So using staging will add to the confusion.
On the other hand, barn is unambiguous (though not used everywhere) and actually quite a nice reference to cows so I kind of like sticking to it.

Another reason is that many other Solana projects use "staging" to refer to devnet/testnet deployment and I'd like to avoid the ambiguity that an external team could think this refers to a testnet.
This is the AI research summary on this:

"Staging" is overloaded: most Solana projects mean testnet/devnet (Anza, Pyth, and the whole skip list). Only Kamino and marginfi use it to mean a second prod-grade program on mainnet-beta — which is precisely what BARN is.

So to avoid the staging ambiguity, both internal and external, I'd use our custom barn keyword!