How did you separate release and development builds?

How did you separate release and development builds?

[Alan Martinovic]

[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]

Hi,
I'm assuming separating development and release builds
is a fairly common use case.
The release build would be something like:

- has all the funcions for production
- attack surface is limited (no ssh, only the required apps)
- config files set with real endpoints (logging or crash servers etc.)

But that's not an image you can really develop on given all the constrains.
So there is also a need for a development image:

- inherits the funcions available on production image
- developer convinence over security (debuggers, ssh access etc.)
- configs set not to depend on payed cloud services


Our curent approach is to solve this by having two different
image recipes.

Pros:
    * Simple to implement (dev inherits production and just adds packages)
    * You can build both at the same time with the same version

Cons:
    * They have the same runtime name (cause they are the same distro)
    * Separating config files is not yet clear
      (one way to have two versions of recipes, which was a lot of
duplication.
       Now we're chacking how to solve it by introducing external
templating (jinja))

How did you apprach it?
Would like to hear you ideas and from the field experiences.

Be Well,
Alan

[-- Attachment #2: Type: text/html, Size: 1659 bytes --]

Re: How did you separate release and development builds?

[Alex Kiernan]

On Wed, Feb 14, 2018 at 9:04 AM, Alan Martinovic
<alan.martinovic@senic.com> wrote:
> Hi,
> I'm assuming separating development and release builds
> is a fairly common use case.
> The release build would be something like:
>
> - has all the funcions for production
> - attack surface is limited (no ssh, only the required apps)
> - config files set with real endpoints (logging or crash servers etc.)
>
> But that's not an image you can really develop on given all the constrains.
> So there is also a need for a development image:
>
> - inherits the funcions available on production image
> - developer convinence over security (debuggers, ssh access etc.)
> - configs set not to depend on payed cloud services
>
>
> Our curent approach is to solve this by having two different
> image recipes.
>
> Pros:
>     * Simple to implement (dev inherits production and just adds packages)
>     * You can build both at the same time with the same version
>
> Cons:
>     * They have the same runtime name (cause they are the same distro)
>     * Separating config files is not yet clear
>       (one way to have two versions of recipes, which was a lot of
> duplication.
>        Now we're chacking how to solve it by introducing external templating
> (jinja))
>
> How did you apprach it?
> Would like to hear you ideas and from the field experiences.
>

The image-mode bbclass from Intel:

https://github.com/intel/intel-iot-refkit/blob/master/meta-refkit-core/classes/image-mode.bbclass

Then just add additional packages in your image recipe based on the
variant you're building.

-- 
Alex Kiernan