Hello there!

If you’re here reading this article you are probably trying to create an efficient continuous integration and delivery system, or maybe you are at the point where you just want to know what would be necessary to achieve this. Either way, I plan on presenting you what we have in place right now and what worked and did not work for us. (Mistakes included - I tried to keep those a bit more lowkey, but anything for educational purposes, right? :D).

This is going to be the first out of a series of blog posts, so please follow us along. For now, I will do a general introduction to the general process of deployment from the perspective of time, scope, and environment. It is important to keep in mind that this refers to the frontend part of an application (and mainly the mobile apps). The applications use React for web and React-Native for mobile, and both of them are written using TypeScript. When I say mobile applications I refer to Android and iOS.

Before starting, let’s see how we do versioning:

Before starting with the heavier parts, let’s see how we do versioning, since it will be mentioned a couple of times in the following paragraphs and blog posts.

We are basically doing semantic versioning, but with some small twists:

  • x - the major version changes when there is a major feature set release - just to have an idea, after 12 months of working, we are still at version 1 (we predict we will release version 2 in the next couple of months, and it will include great new features like allowing application access to guest or non-authenticated users);
  • y - the minor version changes every planned release - we usually do it every sprint, and for us, a sprint takes 2 weeks;
  • z - the patch version increases every time there is a release for a bug fix or a really small improvement.

Environments and way of working:

We are working with three different environments: development, staging, and production.

  • Development gets deployed every time a branch is merged and the people responsible for testing can test the tickets on the go, during the sprint. Like this, by the end of it there is not much to test (or to fix :D). After the sprint is over, our first focus is on the staging environment release;

  • On that day and the next one, the staging release is tested (and we might still push some fixes if needed) and after everything looks good, we go further, to production;

  • Of course, for production we have some rules: we do not deploy on Friday or in the second part of the working day because we want the developers to be present in case something goes wrong. For the mobile apps, we also have an extra environment, we call it the pre-prod environment which is actually the exact same bundle that will later go to production - I will talk more about this in the next post.

My personal opinion is that this type of setup works very well for small to medium applications, which are not centered around sensitive data. This workflow could also fit bigger applications, but in that case, I would definitely add the usage of feature branches.

Up until here, the information applies to both web and mobile apps. The web deployment is fairly easy, it’s just a matter of choosing the right tools and providers for the needs of the application and those of the team.

In the next blog post, I will get into more specific details regarding mobile apps infrastructure and deployments.

Keep an eye on the blog, thank you!

Written by:
Irina.jpeg
Irina Barbos

Trying to bring a ray of sunshine while precision guess working for the development of the empire