This page is written and maintained by Martin Jeret

Why this document exists?

Working with the same product for a long time can create tunnel vision and it’s always good to get back to the basics. Getting back to the basics is what helps us refocus and break free from being stuck in the details.

Teams and people in our company have similar ideas of why people use our product, what value we provide, what our unique selling points are, but struggle to structure those thoughts that would make it easy to understand.

This leads to misunderstandings and misinterpretations that compile into a messaging and product value development that diverges over time and creates siloed knowledge base across teams and as a result duplicates work across teams as we grow.

In this document let's get back to the basics and remind ourselves what is the core value that we provide to our users, what is the difference between value proposition and unique selling points. Why do people use our product and not others?

Summary

What is the core value that we provide to our users?

The core value we provide is to enable people to do agile software development by providing them with a CI/CD tool.

What is the difference between value proposition and unique selling points?

1. Value proposition is related to the core value of what is provided to the users - in our case continuous integration and delivery.
2. Unique selling points are related to why us and not others. First people should understand what it is that we do and if they decide that we would be useful then it is our job to say why we are unique and they should choose us over others.

What is continuous integration and delivery?

I like how Kohsuke Kawaguchi, Jenkins founder, put it (I’m slightly paraphrasing): “Continuous integration and delivery is a development practice that helps automate software releases.” I believe Continuous integration and delivery is essential for agile software development and it eliminates human error from a tedious process.

in this wiki let's stick with the axiom that automating software releases is good. This does not necessarily mean that it is the highest priority for everybody.

When does it become necessary to use continuous integration and delivery?

In other words can people survive without using it? yes. Just like companies have survived, existed and become big in the past. So why now? I believe that the main reason why continuous integration and delivery has become so popular and seen large scale adoption is similar to why cloud has seen so much adoption.

1. Easy to get started and scale as you grow.
2. Speeds up software releases.
3. Improves product quality and stability.

What is continuous integration

Continuous integration (CI) is used to make code changes into the main codebase.

Continuous integration has these stages:

• Develop on local machine.
• Run CI checks to make sure your changes work.
• Try to merge into main codebase - make sure changes are not conflicting with other developers work.

Developers need to be sure that whenever they are ready to commit changes to code that it meets some common standards set in the team. For example:

1. The code compiles in a common standard environment (not just on their workstation)
2. Tests pass

If the changes devs want to introduce meet those standards or quality checks it gives developers feedback that they can trust the changes they are ready to release and that they are not conflicting with other changes (with changes from other developers).

In setting these standards, continuous integration practice encourages developers to commit small changes frequently rather than big changes every once in a while.

As a result it also improves code review quality as the reviewer can focus on other aspects of changes since CI checks are already passed.

What is continuous delivery

this is v0.1 of this document and subject to change.

Continuous delivery is a process that comes from the Agile manifesto:

In CI/CD context, when releasing software there is also typically a process to carry out. This is to make sure that you can release software often and securely. Each team has their own way of doing it, but it usually follows the existing CI pipeline (hence CI/CD) and involves other teams as well in addition to devs e.g. product, quality assurance, manager, beta testers.

**Why do you need some tool for this continuous delivery process? **

1. sharing your application binaries for testing or progress updates means they would need to be shared individually or uploaded to the correct place once the CI pipeline is finished.

The picture is meant to illustrates how connected development teams are and how they need to communicate across different tools and devices. It can and does quickly become quite a tedious process to carry out and can discourage people from sharing incremental improvements.

2. The faster we can make this feedback loop of building and testing the quicker we can get to releasing the application. There are multiple people involved in the testing part.

3. You would imagine the final step of uploading to the App Store or Play Store is easy. Not necessarily.

Continuous Delivery process encourages you to automate even the final mile, which includes, but is not limited to updating screenshots, automating versioning, generating and publishing release notes. Maybe the app has translations and has multiple versions in different languages. These can be automated as well.

Conclusion

If you want to introduce agile software practices then you need to carry out continuous delivery process in one way or another. At Codemagic, we believe that having a robust CI/CD pipeline in place, which you can trust, gives the mobile team the confidence and peace of mind they need to focus on what matters.

This document will continue to be developed.