Test Environment | Community
Skip to main content
P
peeyushbansal
Level 3
February 16, 2023
Solved

Test Environment

  • February 16, 2023
  • 2 replies
  • 2999 views

We have added extra environment that is Test Environment and share JS with developer. But in publishing flow i can move between dev, staging and production. How i can make sure Test script also work. When i moved to staging than acceptance link is working but test environment link is not working.

 

 

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Jennifer_Dungan

For a build that's in prod, whichever dev environment you built during the flow will still have that version of the code (that is until you build a new version of the code)...

 

But if you need to spool up a copy of your production scripts into your new "Test" dev environment, then just create a new library, choose "Test" from the environment drop down, give it a name and build it (all the prod resources and versions will be included as part of the "upstream" resources)

 

In the above flow, you don't need to add any resources. If you look at the library setting, there is a collapsed "upstream" resources.. if you expand this, you will see all the resources that are automatically part of the build.

2 replies

yuhuisg
Community Advisor
yuhuisgCommunity Advisor
Community Advisor
February 16, 2023

Your "Test environment" would fall under Development. In AEP Tags (a.k.a. Adobe Launch), you can only create new environments under Development.

In your workflow, when you create a library, you need to assign an environment to it. So you'd assign "Test environment", so that your library's changes get loaded in your developers' websites.

    P
    peeyushbansalAuthor
    Level 3
    February 17, 2023

    @yuhuisg 

    @jennifer_dungan , i have this library in published (i think prduction), how i can ensure same works at test environment also

     

     

    C
    chirag_madan
    New Member
    September 5, 2024

    No, you still have to build each environment... The Dev environment won't get the "upstream" resources until it is built and deployed.

     

    So let's say you have 5 Environments.... Production, Staging, Dev 1, Dev 2 and Dev 3. (Prod and Staging you can only have one each, but you can have many Dev environments)

     

    Each Library is separate from one another, you can see that each contain resources with a specific Revision Number... 

     

    So let's say in Dev 1 you update Rule A, in Dev 2 you update Rule B, and in Dev 3 you update Data Element X.

     

    Example:

    Dev 1 would have:

    • Rule A (Revision 2)
    • Rule B (Revision 1)
    • Data Element X (Revision 1)

     

    Dev 2 would have:

    • Rule A (Revision 1)
    • Rule B (Revision 2)
    • Data Element X (Revision 1)

     

    and Dev 3 would have:

    • Rule A (Revision 1)
    • Rule B (Revision 1)
    • Data Element X (Revision 2)

     

    If you push your Data Element to Staging and then to Production, those two environments would have the same as Dev 3:

    • Rule A (Revision 1)
    • Rule B (Revision 1)
    • Data Element X (Revision 2)'

     

    But Dev 1 and Dev 2 won't yet see those changes.

     

    The next time you build those environments, they should pick up the upstream values.

     

     

    Now... let's look at a more complex case (I will just use 2 Devs for this example)

     

    Dev 1:

    • Rule A (Revision 3)
    • Rule B (Revision 4)

     

    Dev 2:

    • Rule A (Revision 2)
    • Rule B (Revision 5)

     

    Both Devs have Resource Changes on the same Rules, but they are using different revisions.

     

    If you push Dev 2 to Prod, those are the revisions that Prod will have... but when you make more changes to Dev 1, it will continue to use it's revisions (contrary to what is now in production). In this case, Rule A is newer, and Rule B is older.... There are many caveats here, depending on what work has been done... but odds are you likely want to keep the newer Rule A (Revision 3), but update Rule B to the newest version (Revision 5)... you will either remove Revision 4 from your Resource Changes to pick up the upstream version, or you can update the resource revision here.


    Hi @jennifer_dungan Thanks for detailed explication. I have one scenario, let’s say we have 2 dev websites with different dev codes.

     Dev website1: Dev env1

     Dev website2 : Dev env2


    ruleA published on dev1>staging>priduction.

     

    I didn’t used dev 2 as if now and it is not having any changes. Now when i go to dev website2 will it have the rule published in production in effect as per upstream concept or i have to explicitly create a nee library in and push it to dev 2 to check productioN changes.

     

    Also, we are planning to use a common dev environment code for both dev and staging website as we have to reject changes everytime if we want to remove any other stakeholder changes from staging. Does it seems to be a good idea.

     

    Jennifer_Dungan
    Community Advisor and Adobe Champion
    Jennifer_DunganCommunity Advisor and Adobe Champion
    Community Advisor and Adobe Champion
    February 16, 2023

    So you can have multiple "development" environments, one staging environment and one prod environment.

     

    When you go to publishing flow, in your development flow column, you can create multiple Libraries (in the environment drop down, all the available development libraries should be listed)

     

     

     

     

    If any of your Dev environments already have a Library attached to it, they will appear greyed out in the dropdown.

     

    You will need to create libraries for each "Development" environment.

     

    This is most often used when you have multiple QA/Dev servers (you can create a build for QA1, a build for QA2, etc - and for multiple releases working in parallel where "change 1" may go before or after "change 2"... you can test the tracking in isolation and deploy in whatever order you need)... I suspect in your case, your developers have a separate development environment that they want more isolated from your QA changes?

     

    If that's the case, you shouldn't need to promote your "Test" builds up any further than development.. but when your changes go to prod you will need to sync up your developer's version of the code to what is in production....

      P
      peeyushbansalAuthor
      Level 3
      February 17, 2023

      @jennifer_dungan , i have this library in published (i think prduction), how i can ensure same works at test environment also

       

       

        Jennifer_Dungan
        Community Advisor and Adobe Champion
        Jennifer_DunganCommunity Advisor and Adobe ChampionAccepted solution
        Community Advisor and Adobe Champion
        February 17, 2023

        For a build that's in prod, whichever dev environment you built during the flow will still have that version of the code (that is until you build a new version of the code)...

         

        But if you need to spool up a copy of your production scripts into your new "Test" dev environment, then just create a new library, choose "Test" from the environment drop down, give it a name and build it (all the prod resources and versions will be included as part of the "upstream" resources)

         

        In the above flow, you don't need to add any resources. If you look at the library setting, there is a collapsed "upstream" resources.. if you expand this, you will see all the resources that are automatically part of the build.

          Terms & ConditionsAccessibility statement

          Loading footer...