Git staging for professional Android development

Hello there, Its been a while since I wrote any piece but promise to change this habit to at-least 1 post every week!!

Back to development,

Over the recent months, I have been working on a number of Android projects (both personal and in collaboration with other teams) and I have learn’t several tricks and best practices that worked better for me & for the team and might be of help to you.code

For Android Development, I use Android Studio and Git as a version control.

As a developer, you need to be able to work on a feature,  fix a bug or do code optimizations – and  share with the rest of the team for testing, code reviews e.t.c.
For solo developers, developing and testing in most cases we do it ourselves but when it comes to working in a team of developers, Project Managers, UX experts, Testers e.t.c, you need to have a streamlined process that each team is able to track whatever is happening in the entire project development life cycle.

  • A project manager would need to see bugs getting fixed, issues marked as completed->tested->done to beat a project delivery schedule.
  • Testers need to test whatever has been worked on before its pushed to production
  • Developers need to sit-down and deliver based on the tasks assigned to them in a proper manner.
  • Shareholders need to know whether the core business objectives are being met, all the product milestones are achieved and the impact it has to the business and so on…

In this kind of an environment, a developer doesn’t work on something and push to production, a process has to be created; otherwise some people will be caught with surprises the moment a milestone is not achieved or a bug has not been fixed for months.

Having gone through all this – as a developer and a project lead, we sat down and agreed to have a separate environment’s setup for testing and production.

If you head to Google Play Store app releases, you will notice 3 tabs that represent “Stage rollouts”.

  • Alpha  - A small number of users  (We use it for the team only)
  • Beta – Slightly high number of users (Available to the beta testers who joined from Google play)
  • Production – Available globally on play store (Everyone)

We created 3 branches in our repo to represent each of these stages.

  1. dev (for alpha release)
  2. beta (for Beta release)
  3. master (for Production)

1. dev branch - developer playing ground

This is the branch that every developer who is working on any feature commits on. Be it a new feature, bug or code optimizations. This is where all the testing is done. Once the feature has been tested and is working fine, the lead developer merges it to the beta branch.

2. beta branch - has deployable code

The code that rests here is a tested release so no code edits at this point. If an issue is discovered at this stage, its treated as a bug and should be fixed under the dev branch.

3. master branch - has deployable code

What goes live to the public

With this kind of approach, we were be able to 

  1. Separate testing and production configs – You don’t need to get to a situation where a tester is testing a broadcast feature and blasts a test message to your customers
  2. If you are running unit tests,  you have a “free” environment to easily create them
  3. Right now releases – You don’t need to get to a point where the project owner  wants the latest build released to production and everything is broken because you are working on something
  4. We can easily keep track of how the bugs are being resolved
  5. Project manager can be able to see progress and conversations are based on the issues created
  6. Tasks can be easily organized in milestones from input within the team or a customer request
  7. Bugs can be easily monitored
  8. Differentiate between a rockster and a lazy developer.

be open to share a comment.

Leave a Reply

Your email address will not be published. Required fields are marked *