9 releases tagged with "webops"

The USE_FRAMEWORK_CACHE and USE_NODE_MODULES_CACHE environment flags were deprecated in favor of USE_BUILD_CACHE. The new flag improves the build time by reusing cache from previous commits in newer deploy previews of the same Pull Request.

What has changed?​

The new USE_BUILD_CACHE flag replaces the previously used USE_FRAMEWORK_CACHE and USE_NODE_MODULES_CACHE flags.

To exemplify the improvement, consider the git example below.

master: commit-sha-1
PR 233:
       - commit-sha-2
       - commit-sha-3

Previously, the build correponding to commit-sha-3 would use commit-sha-1 cache. Now it uses the cache generated for commit-sha-2. In case the commit-sha-2 does not exist, the build would use the commit-sha-1 cache.

What needs to be done?​

To use this new improvement, set the USE_BUILD_CACHE flag to true in the vtex.env file of your FastStore project.

The automatic previews of your FastStore + WebOps project Pull Requests are now deployed with GitHub environments.

What has changed?​

Previously, if you committed code to a branch with an open pull request, the vtex-sites bot would add a comment with the link to the PR's corresponding deploy preview. For example:

Now, this comment is no longer provided. Instead, you should check the GitHub environments section. You should see something like this in your pull request:

You can see the available environments on your repository's home page, on the right side of the screen. As of now, there are two environments: FastStore Preview and FastStore Production.

What needs to be done?​

This feature is already active for all projects. There is no action required.

To go live, FastStore projects developed with Gatsby 4 and Next.js require a new environment variable. This new setting relates to improving and automating the hosting flow in WebOps.

What has changed?​

Setting up the SITE_HOST environment variable is now necessary in order to deploy new FastStore websites, developed with Gatsby 4 and Next.js, to production.

Why did we make these changes?​

To improve the hosting flow in WebOps, the WebOps team built a new automation related to this new environment variable.

What needs to be done?​

Open the vtex.env file and add the SITE_HOST key with the main domain specified in VTEX Account Management as the value. For more information, please refer to Configuring external DNS for a custom domain.

+ SITE_HOST= {hostDomain}

Users will now need to authenticate to VTEX in order to access WebOps previews generated for pushed commits in a FastStore repository.

To access the deploy previews, users will need to have access to the myvtex.com domain of the VTEX account indicated either in the GATSBY_STORE_ID from the vtex.env file or the api.storeId entry exported by the store.config.js file.

What has changed?​

Previously, WebOps previews were published to public URLs by default. Now, they require VTEX authentication and are private by default.

Why did we make these changes?​

Deploy previews may include changes to your storefront and new features that are not yet available to the general public. They may also trigger false phishing alerts since they are the same website hosted on a development domain. This change aims to prevent unauthorized access to such content while making the platform more secure.

What needs to be done?​

Every new deploy preview will be private by default. However, to be able to log in and access the private previews, you must install the vtex.faststore-auth app in your account. To do this, run the following command:

vtex install vtex.faststore-auth

If, for any reason, you need your FastStore previews to be accessed by the public or third-party solutions, you may disable authentication by adding USE_DEPLOY_PREVIEW_AUTH=false to your project's vtex.env file.

WebOps now supports Incremental Static Build (ISB), a hybrid server-side and client-side rendering solution. With ISB, only part of the pages are generated during the website build. The others are generated as shoppers start visiting them.

In practice, the first user to load a page triggers its generation. And, once the first load completes, the final page is cached. Then, all subsequent visitors receive the cached version of that page immediately and experience an optimized page loading time.

What has changed?​

To improve the loading time of SKU pages, you can now activate Incremental Static Build for your FastStore project. Part of the store's pages will be generated in each build, but the SKU pages will follow the Incremental Static Build behavior described above.

What needs to be done?​

In order to activate this capability, follow these steps, according to the framework used in your project.

Gatsby​

1. Open your FastStore project and update all pages requesting server data to use the following cache-control headers:

return {
  status: 200,
  props: data ?? {},
  headers: {
    'cache-control': 's-maxage=31536000, stale-while-revalidate',
  },
}

2. Set the following variable to true on your vtex.env file:

USE_STALE_CACHE=true

Next.js​

1. Open your FastStore project and update all pages requesting server data to use the getStaticProps and getStaticPaths APIs.
2. Set the following variable to true on your vtex.env file:

USE_STALE_CACHE=true

Next.js and Gatsby projects deployed with WebOps can now benefit from faster builds. WebOps now counts with a caching system, which avoids the expensive work of regenerating unchanged files.

What has changed?​

WebOps can now reuse outputs produced from previous builds. This change reduces the number of requests for external services and, consequently, decreases building time.

Why did we make these changes?​

These improvements aim to reduce WebOps overhead by enhancing the generation, saving, and deployment of compilation artifacts while also decreasing build time. For example, after implementing these changes, it was possible to notice a decrease from 63s to 34s in the building time of the Base Store (Next.js).

What needs to be done?​

Set the following variables to true in the vtex.env file of your FastStore project:

USE_NODE_MODULES_CACHE=true
USE_FRAMEWORK_CACHE=true

Now every deploy preview will have a new Lighthouse Reports box with quick-access links to reports for all pages you have listed in the Lighthouse CI section of the store.config.js file. That way, you can easily track how each pull request impacts the performance, SEO, and accessibility of your store.

What has changed?​

The Lighthouse CI now makes generated Lighthouse Reports available for developers via Google Lighthouse Viewer for each deploy preview and uploads them to AWS S3. WebOps, then, adds comments on new PRs with links to those reports.

Links to these reports are also shared in the logs of the WebOps pipeline for Lighthouse.

Why did we make these changes?​

These changes aim to make it simpler for you to track how each deploy affects your website's performance.

What needs to be done?​

Nothing. This improvement is already available for all WebOps users. Enjoy!

The WebOps pipeline has been updated to use the newest Lighthouse version. In November 2021, Google published Lighthouse version 9.0. Among its main changes, highlights include the upgrade of Lighthouse APIs, the introduction of new user flows, the redesign of Lighthouse reports, and the addition of new accessibility features.

What has changed?​

Before, the WebOps pipeline was using Lighthouse version 8. Now, we are using Lighthouse 9. As a result, newer audit reports may slightly differ from those previously issued. For more information, please refer to this announcement.

Why did we make these changes?​

We understood that getting different results from WebOps and Lighthouse could lead to misunderstandings, so we made this modification to match both results.

What needs to be done?​

These changes are already available for everyone. Thus no further action is required to use WebOps with Lighthouse 9.

Hello WebOps users,

With the increased number of concurrent users of the WebOps platform, we noticed WebOps pipelines were taking longer to execute. Under high loads, workflows that used to take from 2 to 10 minutes started to span between 20 and 50 minutes. This caused CMS publications to take longer than they should, harming the developer experience.

Earlier this week, we began an investigation into it, and we managed to improve the situation drastically. Our pipelines runtime is now back to the 2-10 minutes range, depending on the workload type and size of the store.

We are working hard to deliver improvements to our platform such as this. Expect further improvements during the closed beta as we work on our platform's stability and performance!