Dynginx: Managing Project Sub-environments in a Development Ecosystem Without Docker

Why was it created?

Dynginx was born out of the need to operate in an environment where Docker could not be used and the necessity for efficiently switching branches for testing. It was designed to automate this process and reduce manual labor.

How does it work?

The process of Dynginx operation:

1. Integration with Bitbucket: When a new pull request is created, Bitbucket hits the appropriate endpoint.
2. Task Queuing: The task is queued in Celery, ensuring asynchronous processing and task management.
3. Application Building: On a remote server, the application is built according to the latest state of the branch code.
4. Folder Copying: After the application is built, the dist folder is copied to a separate location to ensure the independence of the sub-environment.
5. Nginx Configuration: A new Nginx configuration is created for the subdomain, named after the branch name.
6. Nginx Restart: Finally, Nginx is restarted to apply the new configuration and make the test environment available.

Benefits

• Faster Code Review: The ability to test in a full development ecosystem already at the PR stage.
• Error Reduction: Isolated test environments for each branch minimize the risk of unforeseen errors.
• Scalability: The ability to create multiple sub-environments without additional manual labor.

If you have any questions, you can leave your contact information here: https://subscribepage.io/4M6AZq
I would be happy to talk to you!