deployment/README update #15194
deployment/README update #15194
Conversation
| /deployment/<product> | ||
| - package name `<product>deployment` | ||
| - Internal building blocks for changesets | ||
| - TODO: can we make this `internal`? |
There was a problem hiding this comment.
If changesets are the public API of the deployments package then probably yes. Would also mean that we don't break things w/ out knowing for importers of this package.
There was a problem hiding this comment.
I think that's certainly the goal of moving towards internal use. We want to isolate points of contact to truly public information, shared types/apis/etc. and let implementation details stay isolated.
There may be some common code you want to be available for use in integration_tests so not everything would be internal, but it would force an evaluation of APIs, publicity, and that explicit determination is healthy.
| way you can easily test upgrades and support multiple versions of contracts. | ||
|
|
||
| ## View | ||
| A [view](https://github.com/smartcontractkit/chainlink/blob/develop/deployment/changeset.go#L35) is a function which |
There was a problem hiding this comment.
Maybe put a note in here, that this View function will ultimately change to return a Protobuf struct, as we will be formalizing these into a schema. Or I can add one later.
There was a problem hiding this comment.
yeah might make sense to wait till thats more fleshed out
| a set of pointers and interfaces to dereference those pointers from the source of truth. | ||
| The onchain "pointers" are an address book of existing addresses and the Chains field holds | ||
| clients to read/write to those addresses. The offchain "pointers" are a set of nodeIDs and | ||
| the Offchain client (interface to the [job-distributor](##Job Distributor)) to read/write to them. |
There was a problem hiding this comment.
Maybe add that the environment also contains key infrastructural pointers, such as to RPCs and internet end-points for systems we need to interact with like JD.
(Side note, we may need to rethink the question of who owns/knows-about nodeIDs, but that's out of scope for this document change)
| should only depend on deployment/<product>/changeset and deployment/environment. | ||
|
|
||
| ## FAQ | ||
| ### Should my changeset be idempotent? |
There was a problem hiding this comment.
Not relevant for this documentation change, but it again brings up a question of whether we want to make idempotency an explicit signal - that is, if you are making an idempotent change, it should have some explicit signal that it is. Probably too soon to decide this, but it's on my mind.
There was a problem hiding this comment.
I still kinda think it's ok to leave up to product teams as long as we have some examples of both
| environment. | ||
| - package name `changeset` imported as `<package>changeset` | ||
|
|
||
| ## Integration testing |
There was a problem hiding this comment.
Should we have a section that explicitly points to chainlink-deployments, so folks understand this stuff will be used in integration-tests, memory tests, and in real deployments? It's implied, but you're spelling it out here for integration tests. PRobably useful to have a bit about chainlink-deployments, of only to point them at the toher repo's readme.
More background to help new joiners