The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
| Stage | plan |
| Maturity | Complete |
| Content Last Reviewed | 2023-02-23 |
Thanks for visiting this direction page for Pages in GitLab. GitLab Pages allows you to create a statically generated website from your project that is automatically built using GitLab CI and hosted on our infrastructure. This category belongs to the Knowledge group of the Create stage and the direction page is maintained by Matthew Macfarlane (E-Mail). More information about the Knowledge group's priorities and direction can be found on the Knowledge group direction page.
This direction is a work in progress, and everyone can contribute:
Pages is a popular feature and one that people really enjoy engaging with as part of the GitLab experience. It exists at the intersection of multiple stages of the DevOps lifecycle. The long-term vision for Pages is to provide an experience that guides and supports you through Create, Verify, Package, and Release to host static assets on the web, regardless of your level of development experience.
Our immediate focus is on improving the stability and security of Pages. Having a reliable and performant service is our number one priority. Afterward, we'll address our most popular issues and compelling blockers for those hosting static content and documentation.
Futher down the line, we'll validate bigger opportunities around improving the experience of creating and configuring Pages sites and making content management and collaboration easier for non-developer personas.
Now that we have completed the Object Storage re-architecture to support cloud native installations of GitLab our focus is entirely on improving the overall resiliency of the Pages service. We are primarily focused on:
After we focus on reliability, we will look to address some of the most popular features in our backlog that block adoption and unlock more dogfooding opportunities. These include:
The recently deprecated Static Site Editor was conceived as a way to lower the barrier to collaborating on static site content. Publishing a site to Pages is one thing, but collaborating on content with Product Managers, Designers, Marketing Managers, Technical Writers, and executives without requiring a deep understanding of the underlying technologies or programming languages would open the doors for everyone to contribute.
The WYSIWYG Markdown editing experience introduced with the Static Site Editor has evolved into a shared editing component that can be used in many places across Gitlab. With the deprecation of the Static Site Editor as a standalone feature, the vision for managing and contributing to static sites in an intuitive and accessible way will be carried forward by the Pages category.
A future state of Pages could be described as a lightweight content management system (CMS), abstracting away the repository and git terminology in favor of WYSIWYG editing and more accessible publishing workflows. Others like Netlify CMS, TinaCMS, and Stackbit have successfully bridged the gap between git-backed repositories of static assets and visual editing workflows accessible to all. The ideal user journey may look something like:
main.main, triggering another Pages deploy.This category is currently at the "Complete" maturity level, and our next maturity target is "Lovable" (see our definitions of maturity levels). The key features and deliverables necessary to promote Pages are captured in the Lovable Maturity epic.
However, the assessment of this maturity level was made prior to our new process for measuring maturity. We will be conducting a category maturity assessment to validate the current maturity level and understand more about what is necessary to get it to the next level.
We are invested in supporting the process of developing and deploying code from a single place as a convenience for our users. Other providers, such as Netlify, deliver a more comprehensive solution. There are project templates available that offer the use of Netlify for static site CI/CD, while also still taking advantage of GitLab for repository, merge requests, issues, and everything else. GitLab offers configurable redirects, a well-loved featured of Netlify, made available in gitlab-pages#24.
We are seeing a rise in JAMStack and static site generators partnering in the media. This trend toward API-first, affirms our modernization effort of Pages, reinforcing our cloud native installation maturity plan.
GitHub also offers hosting of static sites with GitHub Pages. Key differentiators between the two are:
The most popular customer issues are:
GitLab Pages is dogfooded extensively across GitLab, most prominently as the hosting platform for docs.gitlab.com. Our top internal customer issue is support for versions, or multiple GitLab Pages generated based on branches or tags. Review Apps for GitLab Pages is another important feature for internal usage as the GitLab Internal Handbook is hosted on Pages and would benefit from having Review Apps integrated with the MR workflow.
Adding Review Apps for Pages (gitlab#16907) will allow for more sophisticated development flows involving testing and review of Pages deployments. Enhancing the maturity of deployment would integrate Pages more critically within projects and groups.
Another vision item being investigated is to leverage JAMstack for Pages. The primary goal would be to (enhance the user experience) and allow easy to set up Pages from the UI without expanding APIs. Lastly, in combination with feature flags, Pages can be used to (support A/B testing).