What Are Deployment Strategies?

 What Are Application Deployment Strategies?

An application deployment strategy is a way to upgrade an application with the new version of code. The aim is to make the changes without downtime in a way that the user barely notices the improvements.

In this post, we are going to talk about the following strategies:

1. Recreate: Version A is terminated and then version B is rolled out.
2. Ramped (rolling-update/incremental): Version B is slowly rolled out and replacing version A.
3. Blue/Green: Version B is released alongside version A, then the traffic is switched to version B.     A canary deployment consists of gradually shifting production traffic from version A to version B. Usually, the traffic is split based on weight. For example, 90 percent of the requests go to version A, 10 percent go to version B.
4. Canary: Version B is released to a subset of users, then proceeds to a full rollout.
5. A/B testing: Version B is released to a subset of users under specific conditions.
6. Shadow: Version B receives real-world traffic alongside version A and doesn’t impact the response.

Ramped/Rolling update/Incremental: 

The ramped deployment strategy consists of slowly rolling out a version of an application by replacing instances one after the other until all the instances are rolled out. It usually follows the following process: with a pool of version A behind a load balancer, one instance of version B is deployed. When the service is ready to accept traffic, the instance is added to the pool. Then, one instance of version A is removed from the pool and shut down.

Pros:

• Easy to set up.
• Version is slowly released across instances.
• Convenient for stateful applications that can handle rebalancing of the data.

Cons:

• Rollout/rollback can take time.
• Supporting multiple APIs is hard.
• No control over traffic.

Blue/Green: 

Version B is released alongside version A, then the traffic is switched to version B.     A canary deployment consists of gradually shifting production traffic from version A to version B. Usually, the traffic is split based on weight. For example, 90 percent of the requests go to version A, 10 percent go to version B.

Pros:

• Instant rollout/rollback.
• Avoid versioning issue, the entire application state is changed in one go.

Cons:

• Expensive as it requires double the resources.
• Proper test of the entire platform should be done before releasing to production.
• Handling stateful applications can be hard.

Canary

A canary deployment consists of gradually shifting production traffic from version A to version B. Usually, the traffic is split based on weight. For example, 90 percent of the requests go to version A, 10 percent go to version B.

This technique is mostly used when the tests are lacking or not reliable or if there is little confidence about the stability of the new release on the platform.

Pros:

• Version released for a subset of users.
• Convenient for error rate and performance monitoring.
• Fast rollback.

Con:

• Slow rollout

A/B testing 

A/B testing deployments consist of routing a subset of users to a new functionality under specific conditions. It is usually a technique for making business decisions based on statistics, rather than a deployment strategy. However, it is related and can be implemented by adding extra functionality to a canary deployment so we will briefly discuss it here. This technique is widely used to test the conversion of a given feature and only roll out the version that converts the most.

 Here is a list of conditions that can be used to distribute traffic amongst the versions:

• By browser cookie 
• Query parameters 
• Geolocalisation 
• Technology support: browser version, screen size, operating system, etc. 
• Language

How to fix Kubernetes CrashLoopBackOff

 How to debug/troubleshoot and fix Kubernetes CrashLoopBackOff?

Step 1:

run kubectl describe pod <REPLACE YOUR POD NAME HERE> will give us more information on that pod:

kubectl describe pod nginx-5796d5bc7c-xsl6p --namespace nginx-crashloop

Name:           nginx-5796d5bc7c-xsl6p

Namespace:      nginx-crashloop

Node:           ip-10-0-9-132.us-east-2.compute.internal/10.0.9.132

Start Time:     Tue, 11 Aug 2021 19:11:05 +0200

Labels:         app=nginx-crashloop

                name=nginx

                pod-template-hash=1352816737

                role=app

Annotations:    kubernetes.io/created-by={"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicaSet","namespace":"nginx-crashloop","name":"nginx-5796d5bc7c","uid":"fb9e9518-f542-11e7-a8f2-065cff0...

Status:         Running

IP:             10.47.0.15

Controlled By:  ReplicaSet/nginx-5796d5bc7c

Containers:

  nginx:

    Container ID:   docker://513cab3de8be8754d054a4eff45e291d33b63e11b2143d0ff782dccc286ba05e

    Image:          nginx

    Image ID:       docker-pullable://nginx@sha256:c4ee0ecb376636258447e1d8effb56c09c75fe7acf756bf7c13efadf38aa0aca

    Port:           <none>

    State:          Waiting

      Reason:       CrashLoopBackOff

    Last State:     Terminated

      Reason:       Error

      Exit Code:    1

      Started:      Tue, 11 Aug 2021 19:13:15 +0200

That will help to understand the issue.

Most of the cases you will find are related to configuration issues in deployment.yaml file.

For I found the reference key for the database password was wrong in myapp.yaml file.

I fixed and redeployed I got fixed this issue. here is hilighted key that was wrong earlier.

apiVersion: apps/v1

kind: Deployment

metadata: 

  name: mongo-express

  labels:

    app: mongo-express

spec:

  replicas: 2

  selector:

    matchLabels:

      app: mongo-express    

  template:

    metadata:

      labels:

        app: mongo-express

    spec:

      containers:

      - image: mongo-express

        imagePullPolicy: IfNotPresent

        name: mongo-express

        ports:

        - containerPort: 8081

        env:

        - name: ME_CONFIG_MONGODB_ADMINUSERNAME

          valueFrom:

            secretKeyRef:

              name: mongodb-secrete

              key: mongo-root-username

        - name: ME_CONFIG_MONGODB_ADMINPASSWORD 

          valueFrom:

            secretKeyRef:

              name: mongodb-secrete

              key: mongo-root-password

        - name: ME_CONFIG_MONGODB_SERVER 

          valueFrom:

            configMapKeyRef:

              name: mongodb-map

              key: database_url

---

apiVersion: v1

kind: Service

metadata:  

  name: mongo-express-service

spec:

  selector:

    app: mongo-express

  type: LoadBalancer

  ports:

    - protocol: TCP

      port: 8081

      targetPort: 8081

      nodePort: 30002

Angular 10: Can't bind to 'ngIf' since it isn't a known property of 'div'

 Error: Angular 10: Can't bind to 'ngIf' since it isn't a known property of 'div'

or

can't bind to 'ngif' since it isn't a known property of 'ng-container' angular 11

Solutions:

Make sure to import CommonModule from the module that is providing your component. for me I had to import CommonMudel in the TestComponent

import { CommonModule } from '@angular/common';

import { BrowserModule } from '@angular/platform-browser';

@NgModule({

imports: [CommonModule],

declarations: [TestComponent]

})

class MyComponentModule {}

BrowserModule vs CommonModule

BrowserModule provides services that are essential to launch and run a browser app.

BrowserModule also re-exports CommonModule from @angular/common, which means that components in the AppModule module also have access to the Angular directives every app needs, such as NgIf and NgFor.

CommonModule (all the basics of Angular templating: bindings, *ngIf, *ngFor…), except in the first app module, because it’s already part of the BrowserModule

Flutter: How to fix “unexpected element found in ” error?

 All of a sudden, I am started getting this build error in my Android project:

Error: unexpected element <queries> found in <manifest>

Understanding  the Issue:

To understanding why this happens see the above @CommonsWare's answer

This is because <queries> tag was introduced with new package visibility options for Android 11 and upwards (SDK 30+). Because of that, you need to update your build.gradle with a version that includes this changes. Below is a list of supported gradle options.

The best solution to deal with these errors is to Upgrade your Android Gradle plugin and Update Gradle

You’ll have to update your Gradle version to one of the compatible versions that have the latest query tags (which were introduced with Android 11).

How to Fix it?

To Update the Android Gradle plugin

Specify the plugin version in the YourAppDirectory/android/build.gradle file. The plugin version applies to all modules built-in that Android Studio project. The following example sets the plugin to version 4.0.1:

buildscript {

    ext.kotlin_version = '1.3.50'

    repositories {

        google()

        jcenter()

    }

    dependencies {

        classpath 'com.android.tools.build:gradle:4.0.1'

        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"

        classpath 'com.google.gms:google-services:4.3.3'

        classpath 'com.google.firebase:firebase-crashlytics-gradle:2.2.0'

    }

}

Gradle downloads it the next time you build your project 

To Update Gradle

Specify the Gradle version by editing the Gradle distribution reference in the YourAppDirectory/android/gradle/wrapper/gradle-wrapper.properties file.

Don't forget to update your ditributionUrl in your gradle-wrapper.properties as well. For example, for gradle 4.0.1, you should have:

#Fri Jun 23 08:50:38 CEST 2017

distributionBase=GRADLE_USER_HOME

distributionPath=wrapper/dists

zipStoreBase=GRADLE_USER_HOME

zipStorePath=wrapper/dists

distributionUrl=https\://services.gradle.org/distributions/gradle-6.1.1-all.zip

Flutter: mobX store code generate not working

 

 mobX store code generate not working

I had a same issue and I was able to solve with following steps.

I had this problem today and put these versions and it worked, in case anyone needs

You need to follow just couple of steps. Here is my pubspec.yaml package version for the mobx

Step 1:

• Flutter (Channel stable, 1.22.6)
• mobx: ^1.2.1+2
• build_runner: 1.10.1
• mobx_codegen: ^1.1.0+1

Step 2: run following commands

• flutter clean
• flutter pub get
• flutter packages upgrade
• flutter pub run build_runner watch --delete-conflicting-outputs

I trust it will help you :)

 How to downgrade flutter?

You can downgrade using following setups:

Git Hub Source Code: 

Flutter is versioned using git. Changing the Flutter version is as simple as changing git branch.

Using Flutter Channel:

flutter channel <branch> (example: flutter channel stable)

This command is used to change between branches – usually stable/dev/beta/master. We can also put a specific commit id from git.

Flutter Downgrade Command:

flutter downgrade <version> (example: flutter downgrade v1.22.6)

This command will use a specific version number. You can have the list of the available version numbers using flutter downgrade or here

Then run  flutter doctor and Flutter will take care of downloading/compiling everything required to run this version.

Angular: Cannot Get /

 

I was facing this issue, while visiting http://localhost:4200 **'.

Then, when I opened up a web browser, I navigated to localhost:4200 and a web page with the following text were shown:

Error:  Cannot Get /

Solutions: This is related to most of time is incorrect syntax 

Step 1: open terminal and run "ng build"

Step 2: See the command output and you must find some syntax issue related to your code. Go ahead and fix your issue that problem will be gone