Generally, the acceptance tests are carried out in this environment, but depending on the testing model, it can be carried out in the development environment also. The idea is that if a feature is running perfectly fine in staging, it will run in production also. The staging environment is as similar to production as possible. A thorough check of the code is done at this phase to reduce the bugs.Īfter the testing and the feature is agreed for a release, the code is moved to the staging environment. Various unit, integration testing will be carried out based the testing model in this environment. This is just for you and the other developers to see how new features will work and to try out improvements. The changes you make in the development environment will not be visible to the users when they view your application. It will be connected to a dummy database. By having the environment similar to prod, we will be able to find out issues at the early stages of development. But the best practice is to have it deployed in the cloud or your local datacenter, like a production would be hosted. All the commits made you or your fellow developers will be built and tested in this environment. This is the environment where you develop your code and test it. Among the major environments, the main 3 environments that should definitely be used are development, staging, and production environments. There are many environments like training, PSR, and so on. ![]() Hence we need to devise a strategy, which will be followed by all developers in the team.īefore jumping into the branching strategy, let us have a look at what is environment and the different types of environments.Įnvironment and the difference between development, staging and production environmentsĪn environment in this context, includes the necessary hardware(single or multiple servers), Software dependencies, database, compiler/interpreter, network access for an application to run, and the application is hosted and tested in such an environment. If Developer 1 follows a method, developer 2 follows another method, and so on, it causes a pandemonium. Now that we understand the need for branches, if we keep creating branches as we want, it will lead to an even harder time managing the features. If it is before the merging, we will just abandon the footer feature. Now, if the client says he does not want the footer, we can just revert to commit 7. Once the development is complete, we can merge the branches back into master. Now, if the footer component is throwing an error, it does not affect the header as the header component is in a different branch. Let us say, we create a branch for the header component and footer component respectively as shown in the above image. The features x(header) and y(footer) are coupled together in the master branch, and a change in feature y causes an error, the same error will affect the development of x. And reverting a commit is very common during any feature development. It becomes very hard to track the commits. It becomes so confusing to bring back the previous state. Now we don't want changes in commit 6 and want to revert to commit 4, it becomes harder to track as the changes in commit 5 exist if it is in a different file which is not accounted in commit 4. We can say that when showing a demo of the features to the client, the client says he does not want a footer. ![]() Now let us say that we don't want the latest footer. It may even be you, a single developer, who first wishes to work on the header, then perform a commit, work on the footer - perform a commit, again want to work on the header, and so on. Let us take that we are building a react app and one developer is working on the header component and another developer is working on the footer component. There is a saying among developers that start the day by pull, take a break on commit and end the day by push ![]() It is a general practice to commit your changes very ofter regularly, so that the changes are not missed. ![]() In this post, we will go over why branching is required, the difference between development, staging and production environments, why a strategy is required for branching, and look at a good Git branching strategy.
0 Comments
Leave a Reply. |