Versioning Strategies (Keeping Code and Deployed Models Tied Together)

Hi all!

What is the recommended way to keep my model code (e.g. main.go) tied to the model versions that I’ve pushed to Nextmv Cloud? I’ve currently got two versions of a model out on the Nextmv Cloud. I made a constraint change in V2 of the model.

While I know this, and I commented as such in the description, I would like to be able to pull down the model code from V2. Otherwise, how do I know what code is actually underlying V2? Should I be tagging my Git commits with the model name and version number, and handling it semi-manually like that? Is there a better, more CI/CD friendly way (maybe some Github Actions)?



Hello Everett.

Really good question! The Nextmv Platform is currently not enabled as a code repository. In the backend, it stores binaries and those binaries are tagged with versions. We recommend you doing something in the lines of your suggestion. Take the following example.

  • Your main production branch is named stable.
  • You have a GitHub action (or BitBucket Pipeline, or whatever equivalent) that leverages nextmv.
  • Whenever you are merging new code into stable, you can do something in your action such as:
    • nextmv app push -a <your-app-id> :point_right: updates the latest binary in your app.
    • nextmv app version create -a <your-app-id> -v <your-version-id> :point_right: creates a new version from that binary.
  • Note that <your-version-id> can be the commit SHA, a release version, or any other identifier that helps you keep track of your code as part of your versioning system.

By hooking Nextmv directly into your CI/CD workflow, you have control of versions in a similar fashion as you would releases.

I hope this helps! Let us know if you have any further questions, you can always follow up on this thread. We’ll keep an eye out!

Hi Sebas,

That makes sense! Appreciate the quick reply. That’s similar to how I handle pushing new Docker images for some other things right now.

It would still be nice to be able to view the underlying model code of a given version, as I’m always paranoid that something didn’t push quite right (with any deployment of any technology :laughing:).


Feedback duly noted :raised_hands:. Thank you.

Hi Everett,

In addition to Sebas’ comment on how we do this ourselves in our pipeline, We have a blog and video too that gives a high level overview of strategies to manage operations and deployment, would be great to hear any feedback you have as well.