I’ve recently started using NixOps in a team and one difficulty that we’ve had is doing production deployments with a shared statefile.
I’ve read @ryantm’s Nixops without sharing and while all our machines are currently provisioned outside of NixOps - we don’t know if that will always be the case - so I’m hesitant to adopt the approach detailed in that blog post.
Currently, our statefile is stored in a network share and we move it to a local machine when doing a deployment - this is fine but it isn’t ideal (need to run nixops modify when the expressions aren’t in the same folder, can forget to put the file back, etc). We’ve considered storing the file in our Git repository which would be advantageous because we can keep track of deploys through commits to the statefile, but that raises questions about how to deal with merge conflicts.
What are the current best practices for dealing with NixOps statefiles in a team?
Why not use the no state sharing approach and delay working on this until the time you need the more complex nixops features? At my work we’ve been happily using this approach for over a year, and it has allowed us to do deploys from our CI and our developer machines.
That’s a great point, we absolutely could do that and we probably will - it’s definitely a sufficient solution for the time being to get us going.
However, as we’re just getting started with NixOps and fleshing out our initial infrastructure and processes, if there were a solution that we liked for sharing a statefile that we could set up now and get some familiarity with while it’s still early days, then I think that would be beneficial, so I’m eager to hear what other approaches people have.
We use a wrapper around nixops that handles converting the state to/from json and that is then what is checked in.
In our case that’s fine as we have 1 deployment per customer and it’s highly unlikely that more than one person is working on that at the same time. For the actual shared infra, we coordinate.