Skip to Main content

Frontend Development Workflow

This page covers the regular frontend workflow for Precise Alloy: how branches are named, which local settings matter, how work is handed to QA, and what happens when a change is packaged for backend integration.

This guide is about the normal day-to-day frontend path rather than deployment or backend integration details. If you are starting a task and want the practical version, create the branch with the right ticket ID, check your local configuration once, test the page properly, and then let the packaging flow carry the result forward.

Branching

  • The base branch for all frontend work should be master.

  • When creating a branch for a new feature, use the format features/{ticket-id}-feature-name.
    Example: features/ABC-123-contact-block

  • For bug fixes, follow the pattern bugfixes/{ticket-id}-issue-name.
    Example: bugfixes/ABC-456-contact-block-header-issue

Apart from features/* and bugfixes/*, there are also infra/* and refactor/* branches.

Notes:

  • Always use the task or bug ID as the ticket ID. Do not use the user story ID, because it is shared between the frontend and backend teams.

  • Every branch should include the ticket ID and a short description so its purpose is obvious without opening Jira and going on a small archaeological dig.

  • Delete your branch after it has been merged into the base branch, unless there is a compelling reason to keep it.

Configuration

In /PreciseAlloy.Frontend/.env.development, configure the following values:

  • VITE_PORT
    The port used for the local frontend site.
    The default value is 5000.

  • VITE_BASE_URL
    The base path used to serve the frontend site.
    It should be an absolute path that starts and ends with /.
    The default value is /, but you can change it to something like /static/.

    If you update this value, make sure to apply the same change in /PreciseAlloy.Frontend/.env.eshn to keep local development and deployment consistent.

  • VITE_PATH_EXTENSION
    The extension used for rendered pages in the browser.
    This is usually .html, but it can also be left empty.

  • VITE_TITLE_SUFFIX
    The suffix added to the page title. For example, if the value is Alloy UI, the Home page title becomes Home - Alloy UI.

Deployment

Pushing to or merging into master triggers the frontend deployment process, which updates the published frontend site with the latest changes.

Testing

When your change is ready for Ready For Testing (RFT), use this handoff flow:

  1. Visit the frontend site and inspect the change properly, not just the one happy-path screen that behaved five minutes ago.

  2. If the change is ready, open the frontend task or bug, not the shared user story, and add a comment like this:

    Hi @QA Name,
    RFT.
    URL: paste the frontend page URL here.

  3. Add any extra context that helps QA or the backend team move faster, such as:

    • Steps for executing the test.
    • Integration notes for the Backend team.

Refer to Testing for the full RFT criteria.

Packaging

Packaging is the release-oriented part of the workflow. Use it when frontend changes are ready to be bundled for backend integration.

  1. Create a Pull Request (PR) into master branch.

  2. After that PR is merged, the packaging process runs. It typically executes the required build steps and creates a distribution package containing the bundled CSS, JavaScript, icons, and related files used by the backend team.

  3. If the packaging process is successful, a PR is automatically created from fe-release-inte-package to master.

  4. Review and approve that PR. Once it is merged, the backend team can use the new frontend package. Check the user story to see who owns the backend integration work and let them know the package is ready.