Fast Track Code Promotion in Your CI/CD Pipeline

One of the biggest challenges software development teams face in 2020 is the need to deliver code to production faster. To do this seamlessly, we need a completely automated deployment process, and it must be repeatable through multiple environments. Also, to confidently deploy to production without service interruption, we must have successful tests pass in each layer of the testing pyramid.

Defining this process can be challenging, and visualizing it can be even more difficult, thankfully, Octopus Deploy makes both easy for us! In this post, I define a pre-approved production-ready deployment pipeline as well as discuss the details of each step involved.

---

The automated testing pyramid

Source: https://blog.octo.com/wp-content/uploads/2018/10/integration-tests-1024x634.png

Before digging into our scenario, let’s start by defining our test pyramid. A complete test pyramid has four blocks. The lower blocks have a higher quantity of tests, and the higher blocks have a higher quality of tests. A complete test pyramid provides a high degree of confidence in our deployment success rate.

As you can see from the diagram, the four layers of tests are:

• Unit tests: These need to be successful during the continuous integration stages of our pipeline.
• Component tests: These need to be successful during the continuous integration stages of our pipeline.
• Integration tests: These need to be successful during the continuous delivery stages of our pipeline.
• End-to-end tests: These need to be successful during the continuous delivery stages of our pipeline.

---

Scenario

We have a /hello/world microservice running in production that currently returns a JSON field message with the value hello world! We want to add another response field called status with the value 200 when it returns successfully:

{     
     "message":"Hello World!",     
     "status":200 
}

---

Environments

Source

Organizational policy dictates that any code promoted to production must be deployed in the following environments:

• Development
• Test
• QA
• Pre-production
• Production

Each of these environments are static integration environments, meaning that all components of our application live in each of these environments. We want to ensure we do not have configuration drift. In a later blog post, I’ll discuss how to make static integration environments and ephemeral dynamic environments co-exist within our CI/CD pipeline. For now, we’ll keep it simple.

#software-development #continuous-integration #code-quality #devops #cicd-pipeline

What is GEEK

Buddha Community

Serverless CI/CD on the AWS Cloud

CI/CD pipelines have long played a major role in speeding up the development and deployment of cloud-native apps. Cloud services like AWS lend themselves to more agile deployment through the services they offer as well as approaches such as Infrastructure as Code. There is no shortage of tools to help you manage your CI/CD pipeline as well.

While the majority of development teams have streamlined their pipelines to take full advantage of cloud-native features, there is still so much that can be done to refine CI/CD even further. The entire pipeline can now be built as code and managed either via Git as a single source of truth or by using visual tools to help guide the process.

The entire process can be fully automated. Even better, it can be made serverless, which allows the CI/CD pipeline to operate with immense efficiency. Git branches can even be utilized as a base for multiple pipelines. Thanks to the three tools from Amazon; AWS CodeCommit, AWS CodeBuild, and AWS CodeDeploy, serverless CI/CD on the AWS cloud is now easy to set up.

#aws #aws codebuild #aws codecommit #aws codedeploy #cd #cd pipeline #ci #ci/cd processes #ci/cd workflow #serverless

CI/CD Tutorial for Xamarin Android with Google Play Publishing in Azure DevOps | Part 2.

If you haven’t seen part 1, click here, and start build up your CI/CD pipeline now.

Part 2 Contains:

• Configuring build with creating signed APK, and making artifacts from it
• Setting up branch policy to master

Configure some magic

Let’s go back to Pipelines. Edit your previously created pipeline by clicking the three dot on the pipelines row.

Edit the previously created pipeline

CI is based on cloud machines hosted somewhere over the world. This computers called as agents. They are used to follow your instructions, defined in the yml file. The base Xamarin.Android yml is only to build your code. But we will make some additional steps in order to create a signed APK of every build. Follow up, to complete this setup.

Recommended branching strategy for this is to keep a development branch, and pull request your feature branches to it, and finally pull request the development branch to the master, and keep your master is always at your production version. The figure below shows visually this method. Source: https://dzone.com/articles/feature-branching-using-feature-flags-1

Create a signed APK or bundle from every build

First, set up some variables for this pipeline. You will find a Variables button on the right top of the tab. Click on it.

#xamarin #azure #azure devops #ci #ci/cd #pipeline #pipelines #xamarin

Static Code Analysis: What It Is? How to Use It?

Static code analysis refers to the technique of approximating the runtime behavior of a program. In other words, it is the process of predicting the output of a program without actually executing it.

Lately, however, the term “Static Code Analysis” is more commonly used to refer to one of the applications of this technique rather than the technique itself — program comprehension — understanding the program and detecting issues in it (anything from syntax errors to type mismatches, performance hogs likely bugs, security loopholes, etc.). This is the usage we’d be referring to throughout this post.

“The refinement of techniques for the prompt discovery of error serves as well as any other as a hallmark of what we mean by science.”

• J. Robert Oppenheimer

Outline

We cover a lot of ground in this post. The aim is to build an understanding of static code analysis and to equip you with the basic theory, and the right tools so that you can write analyzers on your own.

We start our journey with laying down the essential parts of the pipeline which a compiler follows to understand what a piece of code does. We learn where to tap points in this pipeline to plug in our analyzers and extract meaningful information. In the latter half, we get our feet wet, and write four such static analyzers, completely from scratch, in Python.

Note that although the ideas here are discussed in light of Python, static code analyzers across all programming languages are carved out along similar lines. We chose Python because of the availability of an easy to use ast module, and wide adoption of the language itself.

How does it all work?

Before a computer can finally “understand” and execute a piece of code, it goes through a series of complicated transformations:

As you can see in the diagram (go ahead, zoom it!), the static analyzers feed on the output of these stages. To be able to better understand the static analysis techniques, let’s look at each of these steps in some more detail:

Scanning

The first thing that a compiler does when trying to understand a piece of code is to break it down into smaller chunks, also known as tokens. Tokens are akin to what words are in a language.

A token might consist of either a single character, like (, or literals (like integers, strings, e.g., 7, Bob, etc.), or reserved keywords of that language (e.g, def in Python). Characters which do not contribute towards the semantics of a program, like trailing whitespace, comments, etc. are often discarded by the scanner.

Python provides the tokenize module in its standard library to let you play around with tokens:

Python

1

import io

2

import tokenize

3

4

code = b"color = input('Enter your favourite color: ')"

5

6

for token in tokenize.tokenize(io.BytesIO(code).readline):

7

    print(token)

Python

1

TokenInfo(type=62 (ENCODING),  string='utf-8')

2

TokenInfo(type=1  (NAME),      string='color')

3

TokenInfo(type=54 (OP),        string='=')

4

TokenInfo(type=1  (NAME),      string='input')

5

TokenInfo(type=54 (OP),        string='(')

6

TokenInfo(type=3  (STRING),    string="'Enter your favourite color: '")

7

TokenInfo(type=54 (OP),        string=')')

8

TokenInfo(type=4  (NEWLINE),   string='')

9

TokenInfo(type=0  (ENDMARKER), string='')

(Note that for the sake of readability, I’ve omitted a few columns from the result above — metadata like starting index, ending index, a copy of the line on which a token occurs, etc.)

#code quality #code review #static analysis #static code analysis #code analysis #static analysis tools #code review tips #static code analyzer #static code analysis tool #static analyzer

Fast Track Code Promotion in Your CI/CD Pipeline

One of the biggest challenges software development teams face in 2020 is the need to deliver code to production faster. To do this seamlessly, we need a completely automated deployment process, and it must be repeatable through multiple environments. Also, to confidently deploy to production without service interruption, we must have successful tests pass in each layer of the testing pyramid.

Defining this process can be challenging, and visualizing it can be even more difficult, thankfully, Octopus Deploy makes both easy for us! In this post, I define a pre-approved production-ready deployment pipeline as well as discuss the details of each step involved.

---

The automated testing pyramid

Source: https://blog.octo.com/wp-content/uploads/2018/10/integration-tests-1024x634.png

Before digging into our scenario, let’s start by defining our test pyramid. A complete test pyramid has four blocks. The lower blocks have a higher quantity of tests, and the higher blocks have a higher quality of tests. A complete test pyramid provides a high degree of confidence in our deployment success rate.

As you can see from the diagram, the four layers of tests are:

• Unit tests: These need to be successful during the continuous integration stages of our pipeline.
• Component tests: These need to be successful during the continuous integration stages of our pipeline.
• Integration tests: These need to be successful during the continuous delivery stages of our pipeline.
• End-to-end tests: These need to be successful during the continuous delivery stages of our pipeline.

---

Scenario

We have a /hello/world microservice running in production that currently returns a JSON field message with the value hello world! We want to add another response field called status with the value 200 when it returns successfully:

{     
     "message":"Hello World!",     
     "status":200 
}

---

Environments

Source

Organizational policy dictates that any code promoted to production must be deployed in the following environments:

• Development
• Test
• QA
• Pre-production
• Production

Each of these environments are static integration environments, meaning that all components of our application live in each of these environments. We want to ensure we do not have configuration drift. In a later blog post, I’ll discuss how to make static integration environments and ephemeral dynamic environments co-exist within our CI/CD pipeline. For now, we’ll keep it simple.

#software-development #continuous-integration #code-quality #devops #cicd-pipeline

How To Setup a CI/CD Pipeline With Kubernetes 2020 - DZone DevOps

When it comes to DevOps, the word that clicks in mind is CI/CD pipeline. Let’s have a look at Definition of CI/CD pipeline:

CI is straightforward and stands for continuous integration, a practice that focuses on making preparing a release easier. But CD can either mean continuous delivery or continuous deployment and while those two practices have a lot in common, they also have a significant difference that can have critical consequences for a business.

• Atlassian.com

CI stands for Continuous Integration, and CD stands for Continuous Delivery and Continuous Deployment. You can think of it as a process which is similar to a software development lifecycle.

• Edureka.co

Systems provide automation of the software build and validation process-driven continuously by running a configured sequence of operations every time a software change is checked into the source code management repository. These are closely associated with agile development practices and closely related to the emerging DevOps toolsets.

• Gartner.com

In the DevOps world, we have a plethora of toolsets that can help and leverage CICD capabilities.

• Docker
• Kubernetes
• Proxies
• Git
• Jenkins/ Jenkins X
• Ansible
• Chef
• Code Pipeline, etc

This blog gives direction to up and running your CICD pipeline running on the Kubernetes cluster by the GitLab CICD pipeline.

Prerequisites

• Hands-on knowledge of Docker containers
• Hands-on knowledge of Kubernetes architecture and understanding
• The Idea of how to write YAML files
• Up and Running Kubernetes cluster

#docker #kubernetes #ci/cd #devops tools #devops 2020 #ci/cd pipeline