Test Cloud Deployments Locally

One of the more time consuming parts of application development is getting an app from a local development environment to a deployed one.

If you’re using Noop that transition happens without effort. But Noop Workshop can make the transition easier, even if you’re deploying elsewhere.

Operational concepts available locally on Noop Workshop include:

• HTTPS endpoints without sending traffic over the internet
• Complete CI/CD pipeline
• Resource Dependencies: Block storage (Amazon S3 compatible API), Databases (PostgreSQL, MySQL and Amazon Dynamo DB), Caching (Redis)
• Private APIs
• Cron Jobs (Tasks)
• Migration Tasks

Local HTTPS

Workshop uses local HTTPS endpoints, mirroring the security characteristics of most deployed environments. Local HTTPS eliminates one of the more common divergences between local dev and production deployments, enabling the development of OAuth flows, setting secure cookies, connecting to secure APIs, etc.

CI/CD

For any reasonably complicated app, it’s hard to predict the exact build and runtime procedure, it’s something developed through iteration. Progress is made by executing a pipeline or deployment process (often triggered by a code change published to source control) running in a cloud platform. It takes time, and lots of it.

Workshop allows developers to experiment with the deployment pipeline locally: refine the build process, run one-off migrations, establish the runtime configuration without sending code to a cloud platform. The result of this iterative development is a locally-running application.

Resource Dependencies

Another challenge that presents itself once an app gets deployed is its connection to Resources (databases, block storage, caches, etc.). Workshop can’t help set up your specific resource connections outside Noop. But while using Workshop it’s straightforward to make those connections, thus allowing you to focus on more important parts of application development.

When you develop using Workshop and deploy to Noop Cloud you can guarantee the resource connections will remain consistent and secure (locally and deployed).

Private APIs

Private APIs (or Service Components) are one of Noop’s killer features. The idea is simple: an API accessible only to other components of an application. It’s a no-extra-effort way to reduce the attack surface area of your apps — and it’s possible to set up and test locally.

In Noop Traffic gets to your application via an Endpoint. The Endpoint decides what application Environment to forward the request to. Once the request arrives at an application environment, the environment will route the request according to the Blueprint route configuration . If the Blueprint doesn’t allow public traffic then requests coming from the Endpoint will not resolve. However, as long as the private component has a route, it is available to other components within the same application via the http://localstack hostname.

Cron Jobs (Tasks)

In Noop they’re called Tasks — they function much like a cron job, with some extra abilities. A Task is scheduled in an application Blueprint. Tasks run alongside all your other application code, so it’s possible to test how the task and the running software function together, again nothing needs to get deployed.

Two other Task callouts:

• Their execution is private. They don’t require a public API endpoint to run. Private execution is a benefit over third-party scheduling services that require a public API endpoint to execute the job.
• They can also run in response to deployment lifecycle events, BeforeServices and BeforeTraffic. These events trigger tasks before new services are created in a deployment and before traffic is routed to the services, respectively.

Migration Tasks

As mentioned above, Tasks can run in response to deployment lifecycle events. These events are appropriate times to make database migrations or otherwise prepare a new release for receiving user traffic.

Workshop makes it possible to observe these deployment behaviors without deploying code to a cloud platform. It’s a low-risk way to validate database updates and ensure zero-downtime deployments.

Reducing Operational Effort

The goal of Noop is to make deploying and running software as close to zero-effort as possible. We believe one way to achieve that is to incorporate some of the operational setup into the local development process.

The concepts above are a start. Our changelog is a good place to hear about our progress. Or start developing with Workshop and let us know how we can improve your development process!

Download our desktop app (which includes Workshop) with the button below. See our intro guide to get started.