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

Thu Jul 28 18:02:22 UTC 2016

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

Why couldn't the UI persist the config data in a form (ascii) that can be
read by humans and tracked under source control?

-- Len

On Thu, Jul 28, 2016 at 7:30 AM, Max Rydahl Andersen <manderse at redhat.com>
wrote:

> 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
>
>
> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public
>

-- 
Len DiMaggio (ldimaggi at redhat.com)
JBoss by Red Hat
314 Littleton Road
Westford, MA 01886  USA
tel:  978.392.3179
cell: 781.472.9912
http://www.redhat.com
http://community.jboss.org/people/ldimaggio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160728/94f52ce3/attachment.htm>