Web development has evolved significantly, with numerous tools and frameworks streamlining the coding process. However, building and deploying web applications has become increasingly complex, often involving a variety of configurations. Seemingly gone are the days of quick deployments with scp or rsync pointing to dedicated or shared hosting servers.
At the centre of all this progress is Git, which has become the industry standard for version control, code management and collaboration. Git has also become the foundation of modern software release lifecycles. This is where Deploio comes in, providing the missing piece to streamline the release process from development to deployment to operating in production.
Deploio adapts to your workflow based on Git revisions, whether you are rapidly iterating in the early stages, have already established a strict release schedule or are maintaining a legacy project with infrequent updates.
And if you are new to automated deployments, you don’t need to set up your own CI/CD pipeline – Deploio will handle building your project and can even run tests beforehand, ensuring an uninterrupted service, all running on Nine’s infrastructure.
Understanding Git Revisions: Branches, Commits and Tags
The following three Git objects can also be referred to as revisions.
Commits: The smallest unit which can be used to make a change in a repository. Unless they are part of a main branch, they might eventually be squashed or replaced with other commits.
Branches: Branches allow additional lines of development to be started, so that different sets of commits can be worked on at the same time. Branches are often merged or rebased with other branches, resulting in a new revision.
Tags: Tags point to specific commits, usually on main branches, regularly used to define a release. They should be considered immutable.
Managing Releases on Deploio with Git
There are numerous software release strategies, often linked to other development practices. To focus on deployment aspects, we have categorized them into three main types, based on their frequency.
Keep in mind that ephemeral revisions such as commits and branches can disappear from your Git repository, causing Deploio builds to fail. In general, running (available) Deploio releases will not be replaced by failed builds or releases that cannot be started.
Continuous Deployments
Also known as rolling releases, continuous deployments are usually tied to a specific branch. Because they allow a high deployment frequency, they are ideal for unstable integration and development branches where fast feedback cycles are desirable.
In the following scenario, a separate development instance is being created for the app based on the ‘dev’ branch. Options such as –port have been stored in the presets of the project configuration layer in advance, so they do not need to be specified:
nctl create application urlshortener-dev \
--project=marco-deployment-demo \
--git-url=https://github.com/ninech/deploio-examples \
--git-sub-path=dockerfile/java-kvs \
--dockerfile \
--env=SPRING_PROFILE_ENV=dev \
--size=micro \
--git-revision=dev # Git branch
Changes made to Commits on the dev branch will automatically trigger a build- and release process on Deploio.
Continuous deployments can also be applied to production environments of course, particularly if mature upstream CI/CD practices and tooling are in place, for example based on GitHub Actions.
Scheduled Deployments
Also known as stable or fixed releases, scheduled deployments roll out changes based on a defined version, which usually has undergone extensive testing. The release version can be reflected by a Git tag and might follow a well-known scheme, such as semantic versioning.
In the following example, a specific version tag is being rolled out:
nctl update application urlshortener-prod \
--project=marco-deployment-demo \
--git-revision=v1.1.0 # Git tag
Ad-Hoc Deployments
Sometimes, deployments are needed outside of regular release cycles. This might involve rolling back to a previous version due to production issues, backporting a change from the main branch to an older release, or directly deploying a specific branch or commit.
Here is an example where the development instance is being used to make a specific feature branch available for testing:
nctl update application urlshortener-dev \
--project=marco-deployment-demo \
--git-revision=feature/dark-mode # Git branch
If required, a specific commit can also be used:
nctl update application urlshortener-dev \
--project=marco-deployment-demo \
--git-revision=e8273c3f # Git commit
Progressive Delivery
As discussed earlier, software can be released in various ways. An advanced approach, particularly suitable for large and potentially distributed applications, is progressive delivery. This involves gradually releasing new features or versions to a subset of users or environments before full-scale deployment.
Popular techniques within progressive delivery include Canary releases and Blue-green deployments.
At the time of writing, such deployments to Nine managed infrastructure are only possible with the Application being deployed to Kubernetes managed by our Argo CD service, for example, on Managed GKE or NKE.
