# What is Devproxy?

**Sygnal Devproxy is part of our development infrastructure. Its basic function is to make it very easy for the development and testing teams to run working code against a live Webflow-hosted site.**

In brief what Devproxy does is to provide special access points to your site, such as `dev.mysite.com` and `test.mysite.com`, that your team can use. When accessing these special versions;

* You can access the full site as normal. 
* Content generally is sourced from your `webflow.io` staged site. 
* Specific code, in particular Sygnal Site Engine, is swapped to use either a DEV or TEST version of the code.

This allows you and your clients to fully test code before bringing it live.

## Development Setup

Typically Sygnal's team uses this setup;

* All coding is done in TypeScript and SASS, using Sygnal Site Engine as a template and infrastructure
* All code is stored in a Github repo
  * Repo is generally public, but can be private with paid Netlify ( see below )
  * With 2 or 3 branches, e.g. `dev` `test` and `main` which is production. 
* We typically use Github codespaces 
* No Github actions needed
* Two sites are setup in Netlify, one for TEST, one for PROD.
  * Both are linked to the repo, to their respective branches
  * Both are setup to auto-update as new commits happen to those branches, making the process hands-free 
    * TS compiling is automatic 
  *

## Workflow

A general simplified ( small team ) workflow looks like this.

### Development

* Developers do programming on their local systems, with the JS and CSS code served from localhost. 
* They push and pull from the `dev` branch in the Github repo. 
* While developing they can make changes to the site and publish to `webflow.io` staging ( only ). 
* To see the code and site changes in realtime, they view the site at `dev.mysite.com`. Devproxy combines the localhost-served code into the staged site HTML and you have a full site experience.

### Testing

In a large-team Devproxy configuration;  

* When the developers are ready to show changes to the client or testing team, they can then merge the Github `dev` branch into `test` 
  * This `test` commit automatically gets picked up by Netlify, and published to the TEST code server
* This automatically recompiles the Typescript 
* Clients and testing team then test the site fully
  * The underlying HTML and CSS are typically sources from `webflow.io`, so that design changes coordinate with code changes 

For the small-team Devproxy configuration, all commits to the `dev` branch are

### Production

*

In general;

* DEVs push and pull to the `dev` branch
* When an RC is ready, the team lead merges the `dev` branch into `test` 
  * This `test` commit automatically gets picked up by Netlify, and published to the TEST code server
* Testing team evaluates it using `test.mysite.com`
* When a release is confirmed, the release manager merges the `test` branch into `main` 
  * This `main` commit automatically gets picked up by Netlify, and published to the PROD code server
  * At the same time, any changes in Webflow would also be published so that the new HTML/CSS design changes are synchronized with the PROD code release 

## FAQs

**Does Devproxy only work with Webflow-hosted sites?**

No, you could export your site elsewhere.

**Does Devproxy require the webflow\.io staging site be published?**

Yes. Most common Devproxy configurations are based on the `webflow.io` site, so that you can coordinate page design changes with code changes. 

**Does Devproxy only work with Webflow?**

No, Devproxy could work with any website, but its design is specifically intended to address limitations of developing with Webflow, and to work with Webflow's specific HTML generation. 

**Can Devproxy sites be indexed in Google?** 

Devproxy always includes a site-wide robots.txt disallow rule to ensure that your DEV and TEST sites to not get indexed by search engines.