Software Environment
Every application that we used is full of hundreds or even millions of code, written by many programmer or developers. To make sure the application is used by users, the dev team is always updating the application. But how do they change the code inside without disturbing users who use it? How they make sure their code is not full of errors and bug before they released it?
This is where environments came in. The concept of an environment is particularly useful when the same application is deployed to different environments. The environments’ independence and isolation from one another creates opportunities to undertake different kinds of activities in each without one affecting the other.
In software deployment, an environment is a computer system in which a computer program or software component is deployed and executed. In simple cases, such as developing and immediately executing a program on the same machine, there may be a single environment, but in industrial use the development environment (where changes are originally made) and production environment (what end users use) are separated; often with several stages in between. This structured released management process allows phased deployment (rollout), testing, and rollback in case of problems.
Development Stage
The development environment is used to build your application. This is where developers complete the majority of their work. Typically, the development environment is set up on local computers, and work is facilitated by a Git repository. Users cannot access anything done in the development environment.
Once your team has a version of the product that they are ready to release, we move to the next stage.
Staging/Pre-production Stage
A stage, staging or pre-production environment is an environment for testing that exactly resembles a production environment. It seeks to mirror an actual production environment as closely as possible and may connect to other production services and data, such as databases.
The primary use of a staging environment is to test all the installation/configuration/migration scripts and procedures before they’re applied to a production environment. This ensures all major and minor upgrades to a production environment are completed reliably, without errors, and in a minimum of time.
Production Stage
The final environment where finished software code is put into action in order to fulfill whatever purpose it has, and where it is used by the end user.
Deploying to production is a particularly sensitive matter, as the clients or users might not be lenient if bugs or errors are found in the final version, or if a new feature does not work as intended.
Software Deployment Implementation
For BisaGo application, I also follow this software environment stage when I am going to develop or do some task. Before knowing this, when I working alone (or in team for the first time), we just push everything into one environment. If I am working alone, there won’t be conflict at all. But as a team? It will bring so much chaos.
To make sure our feature works on development, staging, and production stage, we use Docker container for every stage.. With Docker, I can rest easy when I develop some features and other developers won’t say to me that, “This is not working on my machine”.
Development Stage
Every developers in BisaGo team has their own branch on the Git repository. When I take a task and finish developed it on my local machine, I can push it into my own branch and there will be no conflict with other developers.
If two or more developers working on a same feature, we usually make a specific branch for that feature and those developers can work on their own task. When they are done, they merge it into that feature branch.
When a feature has been fully developed, we moved into the staging stage.
Staging Stage
In this stage, we combined every feature that has been developed and make it into one application. Usually, there will some changes and bugs happens at this stage. The process on our team is quite simple. When a member has done their task, they make a merge request to a staging branch. To approve the merge request, they need at least 2 developers to check the changes and make sure there will no conflict at all. If there is no problem, they can approved the merge request and both branch will merge.
This will repeat until all developers has merge their branch into the staging branch. When everything is done and there is no problem, we can move into the next stage.
Production Stage
For this stage, we need to show the application that has been updated to our Product Owner and Lecturer. If they have some dissatisfaction with the application or they think they found some bugs, we immediately fix it and push it again into the staging branch. Only after there is no problem, we can merge it into the production branch, which in this case is the master branch.
Since the pipeline in the staging passed, the pipeline in the production will pass too. When it passed, it will deploy into the AppCenter, where it will make .apk file, and Google Playstore, where people can download and use the application.
To deploy to AppCenter and Playstore, you can configure it on .gitlab-ci.yml file. For example, this is BisaGo deployment file,
As you can see, the environment only run at a certain stage like staging or production. But, to deploy to a server, we need some important variable like the token to deploy to AppCenter or Staging. Since it is quite of sensitive information, we do not put it directly on the file. Instead, we store it on environment variable and use that variable on the gitlab-ci. Then, the pipeline will run it according to the gitlab-ci.
For Google Playstore, it is almost exactly the same as to AppCenter. You just need to change the token and the target server. Or, if you are interested deploy manually, you can deploy it on Google Play Console, if you have the access.
When you opened your app console, choose Production on the dashboard and it will look like this.
You can see the status of your application release. If you want release a new version, click on Create new release button and it will redirect you to this page.
The steps is quite simple. First, you need to upload a bundle .aab file. Then, name the release version of your application with some release notes. After that, the console will review your release and if there is no problem, it will release it on the Google Play store. Remind you that it will take time to deploy it, so don’t expect it will immediately updated.
The Software Environment is quite helpful when we are developing something, especially if we are going to work as team. I hope this article will be helpful for those who read it.
Well then, cheers~
— A certain person who finally bought a game from his Wishlist
