I've never worked at a tech company. I built an app from scratch with a NodeJS API and MongoDB hosted on AWS.
I will start hiring back-end developers to work with me.
What is the best way to making changes to the backend? All the .js files are stored in a repository, but what's the best way to test changes to the API before shipping?
The app is live on the app store. Should I put a duplicate build on TestFlight and connect it to version_2.js files and test it like that?
Or is there a better way to do it? Curious about what industry folks typically do.
CodePudding user response：
Typically everything that you do should be on git repo, on the git repo you need different branches (typically the main one or any other branch marked as release) will hold the production ready code.Other branches are for new features, bugfixes and development.
While developing i typically use 3 different environments: 1) Local(dev), 2 Server(dev), 3 Server(Prod).
(While being on the development git branch)
-You do the dev and testing work locally on the machine, add the developed and tested code to the development server which also tracks the development branch, do some more testing.
After you decide that the features and bugfixes are done you merge the development branch of git with the production branch and then you pull that branch on the production server which follows the production branch
CodePudding user response：
There are a number of considerations:
Environments
Many would have multiple “environments”. Frequently, you would have at least “development”, “test”, and “production” environments. Many organizations have a fourth environment, adding a “staging” or “pre-production” environment to that mix, something that mirrors production as closely as possible and is the last test platform before going to production.
For each of those environments, you would then have corresponding builds of your app, one that targets each of those environments. Each of those would be a separate TestFlight target so that testers can download and simultaneously run dev, test, and production builds of the app, which would go against the relevant backend.
Testing
There are a variety of types of tests that you should have. At a minimum, you should be thinking about:
- Unit testing
- Integration testing
- UI testing
The building of these tests should be part of your development methodology. You should be automating these tests, doing regression testing with each new release, reviewing code coverage, etc.
Clearly, there are other types of tests that should be run (e.g., stress/load testing, etc.), but the above should get you going.
Source control
You should have all of your code under source control with branches that correspond to your environments (outlined in first point above), so you know what code is placed in which of the environments.
Project management
You will want a project management system that dictates what is under development. Depending upon your development methodology, this will consist of “stories” that describe the work being done (which should correlate to the commits in your source control).
You will often have a kanban board that correlates to these stories to where they are in the development/testing/deployment process and which environment they are in. This is where developers will indicate that code can be migrated to one of the test environments, where reviewers can either send PR back for further development or advance a PR to acceptance testing, where acceptance testers can indicate whether something is ready for deployment, etc.
Semantic versioning
I'd suggest a semantic versioning system. E.g., you might have the server communicate the API version, so that the client knows whether a newer version of the app is required or recommended.
You might also consider namespacing your endpoints. For example, you might be working on v1 endpoints, but when you introduce some breaking changes, that might be v2 endpoints that will be stood up in parallel (at least temporarily) with v1 endpoints. Etc.