Part 9: Getting ENVYous

With today’s installment, we’re going to start digging into actual scripting of the packaging process.  The overall process is fairly simple; for a non-XD image, we load the code we want to package, open the packager control panel, select the appropriate packaging instructions, step through the packaging process, and at the end, assuming there are no problems along the way, we have a packaged image waiting for us.  Sadly, it often doesn’t work quite so smoothly.

All too frequently, the packager tells us about things that we should act on, or possibly even wants us to make a decision.  If we’re doing this in an automated environment, we really just want to record this information and stop since there’s nobody there to make those decisions.  In order for us to make this happen, we have to take control of the packaging process and drive it ourselves.

Scripting this can be done, but there’s a bunch of Smalltalk code that’s needed to do it.  This is fine for a single-image deployment, but as I said at the outset, I have a number of images and more than one environment in which I want to package, and I didn’t much care for the thought of having to modify several files every time I refined the automation process.  I also didn’t want to have to replicate the information from environment to environment.  The information really needed to be kept in a place that was common to all environments, which meant there was really only one logical place.  The packaging information had to go into the ENVY repository.

ENVY is actually capable of storing anything that you can convert to bytes, but it’s extremely stupid about storing anything except Smalltalk source code.  First, space isn’t re-used in ENVY, so every time you put something into the repository, it will grow in size.  Second, there’s no versioning of anything other than Smalltalk code.  If you put a 100K text file into the repository, it will grow by 100K.  If you then modify one byte in the file and put it back into the repository, it will grow by 100K, and it’s up to you to try to differentiate the two versions of the files anyway.  Finally, it’s also up to you to serialize any objects you want to stuff in the repository.  There are methods to handle simple things, but otherwise you’re on your own in trying to flatten objects.

I approached the problem by building an object that could create a packaged image based on its attributes, a build specification.  In the case of a non-XD image, that means the build specification needs to know what config map to load, what packaging instructions class to use, and how to turn that information into a packaged image.   This sort of build specification is fairly simple, and can be stored in the repository quite easily.  By keeping the actual stored attributes as simple as possible and putting the required behavior into methods, I can keep the most important aspects under version control and I’m able to keep repository bloat to a minimum.

A build specification for an 😄 image needs to know what to load to be able to create the 😄 environment (since my goal was to start from a virgin image), the packaging instructions class to use, the information needed to create the passive image, and the config map to load into the passive image.  It then needs to know how to turn all of that into a packaged image too.  Creating the passive image is the tricky bit, so we’ll pause here for now.

Advertisements

0 Responses to “Part 9: Getting ENVYous”



  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s





%d bloggers like this: