[almighty] Architectural Considerations: User based setup (Configs, Wizards, Code)

Thu Jul 28 11:30:18 UTC 2016

On 28 Jul 2016, at 13:07, Pete Muir wrote:

> The other thing to think about here is "infrastructure as code",
> particularly in relation to continuous delivery.
>
> How would someone be able to store the ALM configuration in a source
> control repo, and make changes to the running instance using
> continuous delivery and at the same time support non-technical users
> in making changes (such as the UIs that Miroslav discussed).

Just to make sure we are talking about the same things here.

What ALM configuration are you thinking about specifically ?

I'm currently of the mindset that if you are going for the SCM based
approach then you are on your own and thus non-technical users cannot 
make users via
a controlled UI. What the ALM will then do is more about being a 
destination
for the build to publish results to rather than be automagically 
configured.

This of course does not mean another project in the same ALM can't 
support
a more UI driven approach.

> I think this is definitely a scenario we should support, given our
> focus on supporting companies wanting to use CD/pipelines.

+1

/max

>
> On 27 July 2016 at 08:48, Konrad Kleine <kkleine at redhat.com> wrote:
>> Hi Miroslav,
>>
>> thank you for sharing your thoughts on these three ways to customize 
>> an
>> application:
>>
>>> 1. Via dedicated UI forms, wizards and DSL
>>> 2. Using configuration files
>>> 3. Customizing it in application code
>>
>>
>> I believe that 1. and 2. have a somewhat symbiotic effect. Let me try 
>> to
>> explain what I mean by this:
>>
>> I think there's the act of customizing and then there is storing of 
>> this
>> customization. The later can be a configuration file format (e.g. 
>> JSON) with
>> DSL inside. We use PostgreSQL as our database and this can store JSON 
>> as
>> native objects. The pure act of customization on the other side can 
>> be
>> either writing these JSON files by hand or manipulating them using a 
>> UI.
>>
>> I may be naive but I think the benefit of having a configuration file 
>> format
>> allows for customization right from the start. A UI can be added 
>> later (that
>> is probably the naive part).
>>
>> Regards,
>> Konrad Kleine
>>
>> Software Engineer
>> Red Hat GmbH
>> Werner-von-Siemens-Ring 15
>> 85630 Grasbrunn, Germany
>>
>>
>> On Tue, Jul 26, 2016 at 7:00 PM, Miroslav Hradilek 
>> <mhradile at redhat.com>
>> wrote:
>>>
>>> Hello,
>>>
>>> this is the first of my emails where I will be sharing my thoughts 
>>> on some
>>> design decisions that, in my opinion, are worth considering when 
>>> designing
>>> ALM architecture.
>>>
>>>
>>> # User Based Setup
>>>
>>> So in most applications, and especially ones like ALM, there is a 
>>> big need
>>> for customizing everything like objects, behavior etc.
>>>
>>> It is mostly done in three ways:
>>>
>>> 1. Via dedicated UI forms, wizards and DSL
>>> 2. Using configuration files
>>> 3. Customizing it in application code
>>>
>>>
>>> I've personally had a chance to use all three ways throughout my 
>>> life and
>>> I'm sure the readers are the same. All the methods have pros and 
>>> cons. Some
>>> depend on licensing and their application depends on the skill set 
>>> of the
>>> user.
>>>
>>> # Approaches
>>>
>>> 1) UI etc
>>> This is by far the most consumable method for not very technically 
>>> skilled
>>> people or people not willing to invest in learning the application. 
>>> The sole
>>> configuration form is like reference documentation and configuration 
>>> files
>>> combined. Even higher level of contextual configuration can be 
>>> achieved by
>>> employing wizards which interact with the user until the 
>>> configuration is
>>> finished.
>>>
>>> The downside to this is that it requires the application developers 
>>> to
>>> burn time to code often quite complex forms. Sometimes the 
>>> expression of
>>> such form is quite limited and Domain Specific Language must be 
>>> defined to
>>> overcome this lack of expression. Example being the languages 
>>> describing
>>> mail filters, query languages etc.
>>>
>>> After some time the user learns a lot about the application and 
>>> these
>>> interfaces start to limit his/her efficiency.
>>>
>>> 2) Configuration files
>>> Somewhere in between. You do not have to be a coder to configure
>>> application this way.
>>>
>>> What you have to do though, is to read quite a bit about the 
>>> application
>>> and have a reference documentation at hand. This can be minimized by
>>> including the documentation inside template configuration files in 
>>> form of
>>> comments. The expression is quite limited. Difficult data structures 
>>> and
>>> Domain Specific Languages must be used to overcome this problem.
>>>
>>> 3) Hacking the code
>>> You need to be involved a lot in the application and you have to
>>> understand it's code in order to modify it.
>>>
>>> The expression is virtually unlimited though with little effort on
>>> developers side. No config interpretation code and DSLs are 
>>> necessary. This
>>> can be improved a lot by splitting the configuration part of the 
>>> code from
>>> the system implementation structuring the code as a configuration 
>>> file. If
>>> you include documentation in comments you have a nearly commented 
>>> config
>>> file experience but you still require the user to be quite involved 
>>> in the
>>> app and know at least basic data structures used in the language.
>>>
>>> The biggest downside is that the app often (not necessarily) needs 
>>> to be
>>> rebuilt to perform a change. Second most severe limitation is that 
>>> closed
>>> source applications would be difficult if not impossible to 
>>> configure this
>>> way.
>>>
>>> # How to choose
>>>
>>> There is one important consideration, sometimes overlooked when 
>>> deciding
>>> which style of configuration to employ. Apart from time money and 
>>> developers
>>> personal engagement. It is the TARGET AUDIENCE.
>>>
>>> Who will be configuring which part in reality? How involved are they 
>>> going
>>> to be in the application when in production? What are their use 
>>> cases? Are
>>> there any security implications if I choose this over that?
>>>
>>> These are some of the questions you should consider. And please do 
>>> expand
>>> on this. I'm sure you will have some more options to consider.
>>>
>>> --
>>> Miroslav Hradilek
>>> Quality Assurance Engineer
>>> Base OS Quality Engineering
>>>
>>> Red Hat Czech, s. r. o.
>>> Purkynova 99
>>> 612 45 Brno, Czech Republic
>>>
>>> _______________________________________________
>>> almighty-public mailing list
>>> almighty-public at redhat.com
>>> https://www.redhat.com/mailman/listinfo/almighty-public
>>
>>
>>
>> _______________________________________________
>> almighty-public mailing list
>> almighty-public at redhat.com
>> https://www.redhat.com/mailman/listinfo/almighty-public
>>
>
> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public

/max
http://about.me/maxandersen