HOW can promotion be handled, with HARD CODED SNAPS?

[stephenknilans]

Please read the entire message before answering.

In many companies, production promotion is handled by people that either aren’t, don’t want to be, and sometimes are forbidden to be, knowledgeable about things in that domain. Their job is simply to follow protocols, read promotion instructions, and faithfully execute them. If there is any problem, they report in to the submitter, etc… Frankly, I wouldn’t want to do this manually anyway. Too many things need to be changed and it would justify another test, which can’t be done in production.

To that end, I used newer snaps that handled expressions, to make a product that will AUTOMATICALLY promote to anywhere in the entire enterprise. It is nice because one parameter sets that, and a blank setting sets it to a default, so dev will run with default dev settings, and production will run with production settings by default. This code REQUIRES, NO…, DEMANDS, that we have features that are 99% only in the snaps. Without them, there is simply NO way to automatically promote using snaplogic, because the snaps require values that CHANGE from environment to environment, and the OLD snaps require that the changing values be HARD CODED! In snaplogic’s Defense, snaplogic didn’t write the snaps I seem destined to have to use.

It seems the only option I have at this point for one case is to change a hardcoded snap automatically upon promotion. The change would be a standard one for the environment.

So my question is has anyone done this before? If not, are there any APIs to facilitate the import and export, programmatically? I have a limited time to get an answer, implement and test.

BTW I am trying to only give enough details to answer WHY I have the problem, and the limited timeframe, and why I have to do it, and what I need to do. Ideally, we want to hand stuff to the production team with SIMPLE instructions that they can quickly follow, and keep reusing.

[jhagist]

We are faced with a similar issue. We chose to go do the route of creating configuration files that are added to the library in the pipeline. That way a developer can modify the file prior to promotion and all operations needs to do is load it. That means that the hard coded values need to go. I don’t know of a way around that. 🙄

[jhagist]

I am voting for option 2. Just don’t see another way around it.

Community… ideas?

[smanoharan]

@stephenknilans:

Let me make sure I understand things clearly.

1. This particular snap only accepts Hardcoded values and not expressions.
2. The company or the people in charge of dealing with the pipelines do not want to upgrade this snap for some specific reason.

One of the approach is to have a private snap pack for this snap with some modifications like keep all the details the same as the previous one and the only difference will be that it accepts expressions.

I understand that you are in a time crunch. Can you tell me more about this “ONE” snap so that I could see what we can do.

[stephenknilans]

I was hopeful that I guess I would find a way of easily doing this through an API, cumbersome as it would be, or there was another way to do it. I guess there isn’t. I have removed certain responses I made, and left this post merely to explain my position. I will continue through other channels, and work on a temporary fix, should the worst situation arise. It is only one value, and I will create parameters for another issue the customer wants so they can funny implement it later, if possible.