Use environments

Welcome to the set up a development environment course. My name is Doug Crookston and this training will explain what a Launch environment is and the three types of available environments.

An environment contains one or more working versions of our Launch libraries to be hosted of different URLs. When a property is created, three environments are automatically added, the development, staging and production. These three environments correspond to the typical web environments in the tag development and release process. Tags are first created by a developer in the development environment. When they’ve completed their work they send it to the staging environment for QA and for other teams to review. Once the QA and the other teams are satisfied, the code is then published to the production environment which is the public facing environment which our visitors experience when they come to your website. The benefits of this is so you can safely add new features and make implementation changes available to the right users such as the developers or the QA engineers and the public at the right time.

Launch also allows an unlimited number of development environments, which is very useful for multiple developers working of different projects at the same time for the same website.

There’s two other definitions that we need to understand because they work hand-in-hand with the environments. A library is a set of static JavaScript files that contains the specific build code for one of the three specific environments. It’s self-contained and it doesn’t need to call back to the server to retrieve new data. Now the embed code is a script tag that is generated when an environment is created. It’s placed on the webpages of the site that links to the location of the library file.

Let’s dive into Launch now and walk through creating a new development environment.

From the overview page here on Launch, we can click on environments.

Here we see the three environments that were automatically created for us. Now you can click on anyone of these and you could change the name if you wanted to. Also we could change the host. This is why it’s important to create our hosts before we come into the environments tab. We also have the option to create an archive. And if we have an archive we need to give the path to that library. And we could also encrypt the library if we wanted to and we would need to include a password. We’re going to go ahead and skip that and come back out. In a common Launch implementation, there may be several developers or teams working on separate tasks at the same time. Each team or individual developer can have their own development environment. This allows them to work independently without stepping on each other’s toes. Or in this case, each other’s code. Development environments are intended to be used to iterate through the changes to ensure that the business logic actually behaves as expected. Let’s add another environment here. We click add environment in the top-right, and here we can see that we can only create new development environments. For the QA process we can only have one staging and one production environment. Let’s click the select under development and it gives us this new environment and we want to give it an intuitive name. Here I’m going to call it; Doug’s dev team. Now this is where I can pick the host and we highly recommend that we use managed by Adobe specifically for the dev environment because this allows us to check our code on the website immediately and we don’t have to move any files around. We could also do an archive but I’m not going to do that. So we’ll just click save here in the upper-right.

Now Launch just created the embed code for our new environment. This embed code is the line of JavaScript that we’ll place on the pages of our website to reference our library. Notice at the end of this code that it includes the word development. Now this is the best way to check to make sure we’re placing the correct embed code in the appropriate version of our site. And in the other ones, for example staging, would say stage at the end of this. But our production would have nothing at the end of it.

Now this line of code is placed in the head tag of our pages. Now most websites have a template and if you put this in the header of the template, then it would be replicated to every page of the website. The other key point of an embed code is that we have the option of having this library load on our websites synchronously or asynchronously, as shown here in the upper-left. We also can see this async in our code line near the end.

When we toggle this switch it moves it from asynchronous to synchronous. And notice now that in the synchronous we not only have our head tag but we have a footer tag as well. So we can choose to do this either way. But there are legitimate reasons for using async or synchronous depending on the implementation needs.

We want to use asynchronous when the page rendering is independent of other tagging processes that are going on. This is more efficient because once the process starts, the next one immediately begins, not waiting for the prior one to finish. Usually this is much faster than synchronous. And this is because the code executes in parallel. Adobe recommends using the asynchronous method unless there are specific needs that would require a sequential loading of the page and tags. As mentioned earlier asynchronous only uses a header tag and will include async near the end of our code.

Now in contrast, synchronous should be used when one request or process depends on information from another request before it can proceed. This is called a blocking script because the second process is blocked until the first one completes. Synchronous can also be used when several requests are dependent on the same processor. In this case, async will not speed anything up but can actually result in more overhead work for the processor. And also remember that there’s two lines of embed code for sync; the header and the footer script.

So in this case we can go ahead and close our embed window.

Now if we want to pull this up later, we can simply click on this little package icon and it will pull up our embed code again. Then at the right of the embed code we can actually click on this copy symbol, it’ll copy it to our clipboard and then we’ll go ahead and paste it into our website. Before we leave I just want to point out these two links that will help you when you’re debugging and are very powerful tools. They will use this embed code in the debugger and the auditor.

Once our embed code is placed on our pages and the tagging is working as designed, the developer will send their development library to the staging environment for review and approval. Once the library is approved it will be published in the production environment. This is done in the publishing tab that we talked about in another video. But this process won’t work until we put the embed code for the staging and for the development websites on those websites. -