Improbable Icon

Suggested Assembly and Deployment Nomenclature?

v9-0-0

#1

In the tutorial for Hello World, we’re told things like…

Run spatial upload my_assembly_name. (You can change my_assembly_name to something of your choice, if you like.)

What’s the consensus for naming assemblies and deployments? Something like a version number, or “public test initial” or what? Should the name ideally include the name of the whole project to be descriptive, or should we treat them more like Git commits such as ‘added enemy ships to level and fixed collision detection’?

I would appreciate it if the tutorial gave us enough of an idea to answer these questions. Thanks!


#2

I name my assemblies and deployments using the following scheme:

name_of_project_yyyymmddhhiiss

Where the latter part corresponds to the date and time when the assembly was built (the order of the datetime parts ensure that it a listing of assemblies is always in the chronological order).

When I make a second deployment from the same assembly (rare currently) I append the above name with a followup number.

This format ensures that all my assemblies have a unique name (it is impossible to have 2 assemblies built within the same second) and that I can use tooling to generate that name. Currently I have a very simple bash script to start a remote deployment:

TIMESTAMP=$(date "+%Y%m%d%H%M%S")
spatial clean
spatial build
spatial upload elrakis_$TIMESTAMP
spatial snapshot upload [my_spatial_name] elrakis_$TIMESTAMP snapshots/initial_state.snapshot
spatial deployment launch [my_spatial_name] elrakis_$TIMESTAMP deploy.json elrakis_$TIMESTAMP --cluster=eu3-prod

I hope that helps!


#3

I use a similar approach.

I typically use the same name for my assembly and deployments and usually name them in a format like below.

date, thing I’m deploying, thing i’m testing or adding, deployment number for that day

170126helloworld_morefire_1


#4

Hey @Hunter-Bobeck,

Formal consensus for naming assemblies and deployments is not something we’ve documented but @draconigra 's timestamping approach is definitely what we’d recommend! I’ve also put forward the feature request of being able to add a description to your deployments git-commit-message style so you’ll also be able to express your having ‘added enemy ships to level and fixed collision detection’ while using timestamps for the actual names - do you think this would be useful?

Thanks and great question! :slight_smile:


#5

Ooh, I was thinking about automating with a script myself. Thanks for kickstarting it, your formatting makes sense too.


#6

Personally I think it would be best if the timestamping approach was automated; that way we don’t need everyone to write a script / reinput that code each time in order to put a time on each assembly and deployment pushed. That seems to make a lot of sense for organization. That should just leave one description field for the user to actually fill in – the very commit-style feature we’re talking about…

git commit -m 'this text is the part I'm talking about'

Automate everything possible, that’s my approach!


#7

Good question @Hunter-Bobec!

When I’m moving between branches or updating my SpatialOS version, I use unique names for my assemblies. However, when I’m developing on the same branch and making minor code changes, I keep the same assembly name. The advantage of doing this is that subsequent uploads to an assembly only upload the diff between the two assemblies, which makes it a lot more efficient – something you notice for large projects with many big assets.


#8

Good to know, thanks.


#9

Interesting; what you are basically saying is that it can be quite efficient to re-use the same deployment name when you work on the same branch? Because that could change my flow quite a bit :slight_smile:


#10

Perhaps the timestamping would be better limited to days, instead of going deeper into hours and minutes and seconds.


#11

By the way the creation time is listed in the console so perhaps timestamping is altogether redundant.


#12

Not reusing the same deployment name but reusing the same assembly name :slight_smile: But sometimes it makes sense to reuse the same deployment name as well.