What is the normal process for working with Postgres in a Node, React, Express application?
In that past, I've used MongoDB Atlas to quickly create and host a database for my development environment. My current project is using Postgres for the database, however, I'm trying to figure out the process/workflow.
For example, trying to find a Postgres as a service equivalent to Atlas, Heroku and Digital Ocean seem to match that bill. However, it looks like Heroku needs a deployed project to work. I don't want to deploy yet and really just want a development database.
Is it normal practice for everyone on the project to spin up a local Postgres database and then deploy/host a single production database at the end? Thanks for the help!
I would suggest following workflow that I've recently used on a project.
local instances on docker or something (feature development purposes)
first staging instance that could be used as stable dev env (can be used for specific feature testing, or as a internal testing environment)
second staging instance where stable master branch with hashed prod data can be used for external testing
prod or prod mirror, depends on project requirements
It would be also helpful to have migrations within the code, so that you can keep track of DB development as well. Also look into https://sequelize.org/ as it could be helpful.
Related
I have recently started using Azure Dev Ops to manage the code of my ASP.NET Core Web Application. I followed the Microsoft online guides for setting up Azure Dev Ops, but, the tutorials are basic and assume that you're always pushing to production through your pipeline. In my organisation, that's not the case and I am looking for some guidance and clarification on my process and how it can be achieved.
My Scenario
My project has two branches master and staging. The staging branch has all the feature I'm working on that need to be tested by selected users in my organisation, once those features are tested they are merged into the master branch and pushed to production for use.
What have I done so far?
I have created a pipeline for CI/CD that builds and releases every time the master branch is synced.
I have created slots on my Azure web app, one for production and one for staging.
What do I need help with?
I need to understand how I deploy the changes I make to my staging branch to my web app staging slot in Azure so that people can test the new features.
How do I use these branch filters that I've seen?
Is it better to use the filters or triggers?
What do I know?
I've seen that there are tags and filters that can be used but I'm lost on how they would apply to what I need to achieve.
I attempted to put a stage in my release that pushed the project to the staging slot in my web app, the problem with that is that it's always the master branch and I don't want to release features for testing on the master branch.
I'm sure it's a simple setup, but I'm struggling to get it locked down. Any help would be appreciated.
Use a separate pipeline, that triggers on changes to the stanging branch.
We want to start working with liferay. But the server is too heavy and the developpers computer don't have enought RAM. We want to centralize the server instance.
In other words, we want to build a development server where all developpers can connect and directly develop in their web browser, compile, view the result and push the code to git repository.
I found some good cloud IDE like eclipse CHE and a good maven archetype for liferay projet. So i can build the projet with maven. But now i want to know if it is possible to configure Liferay like every developpers can work without troubling another. And if possible, How ?
The developpers can share the same database and can use different port. Maybe, the server can generate tempory URL like some online cloud editor.
I found this post Liferay With Multiple Server Instances, but i don't think is the best way because he create one server per project. I think is too heavy.
If necessary, We have kubernetes in our IS.
Liferay's tomcat bundle, by default, is configured to take a maximum of 2.5G for the process, but it can run with far less - the default only recently was bumped up, because many people never change the default and then wonder why production systems run out of memory. For 1 concurrent user (the sole developer) on a machine, I guess that the previous default of 1G heap space is enough. Are you saying that that's too much for your developers' machines?
Having many developers on a shared server poses one problem: Yes, you may deploy different code from different machines, but: How about setting a breakpoint? Can you connect with multiple debuggers? If something fails, how do you know whos recent deployment caused the failure?
Sharing a server is an integration technique, not a development technique. If your developers don't have enough memory available for running their own Liferay server next to their IDE, it's a lot cheaper to upgrade their machines than to slow them down when everybody is accessing the same server and they can't properly debug. You pay the memory once, but your waiting developers by the hour.
Is it possible to share one server? Sure it is.
Is it possible to share one server without troubling each other? I doubt.
When you say: You think it's too heavy: What are you basing that assumption on? What does the actual developer machine look like and what keeps you from investing in the extra memory?
It's trivial to share some infrastructure - i.e. have all of them connect to the same database server (and give everyone their own schema). But just the extra effort and setup might require you to pay the developers by the hour as much as you'd otherwise pay for a couple of memory chips.
And yet another option is: Run Liferay on a remote server, but keep 1 instance per developer. This way you don't need the local memory, but can have the memory in the cloud. Calculate if you pay more for remote cloud machines than for local memory - that decision is up to you.
Currently at my company, we have three servers: Development , Staging, and Production.
When a new feature is requested, it is developed in the 'Development' environment (server/VM). Once the developer is satisfied that it's complete, they move it to the Staging environment and test it. Once it is fully tested, it is moved to the Production server.
The problem is that the team is very small and it's hard to manually maintain the Staging and Production Environment. We need the staging environment to be exactly like the Production environment, and it is time consuming task to do that manually everytime.
Is there a software out there that can help? or a process?
One method we thought could be possible is Cloning the Production Environment every time and use it as Staging. Once the feature is tested, merge the two VM's. But that might take a lot of time and cause downtimes on production environment.
Any hints/suggestions?
Thanks
I would suggest you to have a look at an environment provisioning tool like Ansible, Puppet or Chef. It requires some time to get used to it but after that you'll be able to auto provision any system (be it a server or just a developer machine) with just a few terminal/command line commands.
The development environment is obviously for developing the web app locally.
The production is the operational public website with everything as the final version.
what is the testing environment and what is the difference between that and staging environment?
and if its what I think it is, why not just deploy to an alternate website address and use that?
The testing environment is an environment in which Rails will perform the tests that you write. This is a slimmer environment in which certain things are disabled such as sending emails, and loading the asset pipeline. The database in the test environment is also generally not persisted between test runs.
For more information on how and why to test your rails applications check out the Rails Guides. If you are not currently testing your applications, you should really start as it can save days of hunting for broken code, and many many headaches down the road.
Staging environments are setup to mimic most of the functionality of a production environment. The staging 'stack' should be as similar to the production environment as possible; e.g. same hardware, same OS, same installed packages, etc.
Things I generally limit when setting up a staging environment are email sending, I will use a mail interceptor to send all email to my address. Think of the staging environment as a sandbox in which to test changes to your production environment, without actually testing in production.
For most small apps, a staging environment is not always necessary. However, for a large, enterprise level application it is a must as you generally cannot afford any downtime for your production system. With the staging environment you can catch those changes before they are pushed to production.
Hope this helps.
hey everyone.
ok, a little background to the project... I've released a program to a couple clients that use a WCF service for them to connect to our servers in the office. Being that i used the clickOnce setup utility in VS2010, when i am doing testing on a VM i publish to a different spot on the server as to not give untested code to clients. However, the WCF service only gets published to one place for both versions (development and release).
What i'm working on now requires a change to the WCF service as a couple additional things get transferred between client and server. If I publish the modified WCF, will it affect the current clients, or will i be able to test my development version with no worries? I'm afraid i already know that the answer will be, yes it will affect them.
thanks!
dave k.
Isolation of test, dev and production:
Whenever you need to test something or put it in production, you need a separate environment. So you need a separate machine to develop and do local testing, another to test the checked-in code (for use by a tester, a customer etc.), and another to run the production code -- at the very least.
If your service interacts with other software, especially with software that gets updated a lot, this is an important way to make sure that you don't introduce side-effects and that what you build will be compatible with what is running on your production server.
So: isolate and make your test environment a "clone" of your production environment.
Two versions in parallel:
If you update your own code for customer X, you can still host a previous version of your production code for customer Y on another (virtual?) server. Customer Y can then choose when to switch to your new version, after which you can take the old code out of production.
You should create a seperate VM for your test environment.