Your app may be live, but it is far from complete. Over time, users will find new bugs or will suggest new features that could take your app to the next level. No matter the quality of your app, you will eventually need an update. While updates may seem daunting, a simple development strategy called versioning makes the complex clear and coherent. Follow our straightforward guide to versioning to see how Fyresite streamlines the update process.

Environments

To update your app with new features or patches, we need to edit the software. However, changing live code would break the application for the user. As a result, we need to keep our developing code and our live code in separate places. These different locations are called environments. Every app has at least three different environments: Development, Staging, and Production. Each of these environments is configured for a specific purpose.

Development

development environment - a crane lifting a box

The Development Environment is where the developers build and add new features. When a developer finishes a new feature, they deploy it to the development environment. If the code does not work or if major bugs surface, the development team fixes errors before deploying further changes. This process continues until features work as intended.

Unlike the other environments, the development environment is not configured to reflect an average user’s device. A user will access the mobile app on a smartphone, not a computer. The user will lack the IDE, compiler, and an array of other tools that are crucial for the developer. Put simply, the software in the development environment does not reflect the final product. While the final production environment will work one way, the development environment is more malleable to fit the needs of the developers. The result is a better developed and more powerful product.

One of the most notable differences between the development environment and all the other environments is that it is not connected to servers. All the code is local and can only be accessed by developers. This difference is huge: it allows the development team to work on updates in an isolated environment without disrupting the live app. Any rudimentary features and updates have zero impact on the app that the user sees. As long as code remains in the development environment, we can manipulate it without users noticing.

Staging

staging environment - a stage spotlight

The development environment is critical for keeping developing code away from live users. However, since the development environment is configured uniquely, moving code directly from the development environment to a production environment would be a disaster. That’s why the staging environment is so important: it allows our teams to test the product and prepare it for launch.

The staging environment is where all the QA, testing, and experimentation takes place. It serves as a buffer between the development and production environments where our team can add a final polish before any new updates go live. Since we use the staging environment for both tests and pre-launch preparation, it needs to be as similar to the production environment as possible. Every single detail from hardware to caches needs to be an exact copy of the production environment. The only difference is that the staging environment is not live. That way, our team can test the product in a realistic configuration without breaking it for active users.

Staging is home to our QA tests. We cannot QA in the developer environment because the configuration is different, and we definitely cannot QA in the production environment because any errors would be exposed to all users. However, the staging environment gives us the freedom to break the code over and over again. Whenever we finish developing a new feature, update, or patch, we run a series of tests to find as many bugs, errors and crashes as possible. Find out more about Fyresite’s QA process.

Once the application has been approved, we resubmit it to the app store and move to the production environment.

Production

production environment - bricks and trowel

While the other two environments have been private to some degree, the production environment is a real-time setting in which end users interact with your code live. Before pushing any updates to the production environment, most of the bugs should be removed. However, the production environment may also provide further insight into potential errors and areas of improvement that we can repair in future updates.

While the production environment is often associated with a sudden, immediate launch, that option is not the only one available. Many companies prefer to roll out updates to a select number of users over time. The update is still moved to a production environment, but it is only accessible to certain users. Over time, more users gain access to the software. Rollouts are great for location-based betas and MVPs, but they also serve other purposes. Some companies may want to roll out an application slowly to avoid putting too much strain on their servers. Depending upon your AWS infrastructure, these issues may be nonexistent. Feel free to explore your options with us so we can determine what update strategy is best for you.

Organization With Git

organization with git - three boxes and an arrow

Tracking and deploying the code to different environments requires Git repositories with special permissions. The repositories organize information on how a project changes over time with parts called commit objects and heads.

Commit objects contain information about the project at a given point. They link to a parent commit object, which describes the software before the changes were made. Parents commit objects come first chronologically. A head references the most recent commit object in a branch.

Between these parts, a developer can track and visualize the history of a piece of software over its life. That way, multiple people can work on a new feature at the same time without getting in the way of someone else. Once a developer completes edits in an isolated location, they can merge the changes. The resulting code is much more streamlined and takes less time to develop and QA.

If you want to learn more about Git repositories, check out this guide.

Importance of Versioning

Reliability

Versioning your software always results in more reliable code. By splitting up development into three or more environments, we can catch bugs early on in development. Pushing code to a new environment requires scrupulous review. Additionally, when code is in the staging environment, we can brutally devastate the code in a similar configuration without ruining the user experience. That small change makes the QA process much more efficient and exact without any risk.

Another advantage of versioning is that the code is backed up at each stage. Since the repository tracks changes made over time, we can quickly determine what changes went wrong and restore a previous version. Since we can identify problems more efficiently, we can also solve them more easily. The resulting code is much more reliable.

Collaboration

Having multiple people edit the same code at the same time gets chaotic without Git. If two developers work on the same file at once, an edit can break the code. However, two developers working on separate copies of the same software gets just as confusing because there are multiple copies of the project
However, branching makes collaboration seamless because developers can work on edits separately and merge the results later. That way, there is still only one copy of the project, but multiple people can work on it at once.

Clarity

Updating code without versioning involves editing files stored on a hard drive without ample consideration of continuity between developers. That process will get very confusing very quickly. Without good record-keeping, developers may get confused about the difference between versions, or what the current state of the code is. Without proper communication, someone may even push an update that is far from complete.

Versioning solves this massive problem by making the state of the software as clear as day. The repository has all the information you need about the difference between versions and the environments indicate how close the update is to launch. Don’t rely on unorganized notes when you could rest easy knowing for certain that everyone is on the same page.

Updates seem difficult, but with our versioning process, they are simple and streamlined. We use Git repositories to track changes and move code between three different environments: Development, Staging, and Production. As a result, all updates are clean and reliable.

When is your app due for an update? It may be sooner than you think. To get an evaluation of how we can improve your app, contact us online or call us at 888.221.6509.