Monday, February 14, 2022

GITLAB: CI/CD Pipeline intro to the .gitlab-ci.yaml





CONTINUOUS INTEGRATION - CI [THIS IS ALL AUTOMATION, NO MANUAL NEEDED]

Its a devops process.

When developers starts coding,

then we will want to manage that code, so he uses VCS(version control system) / SCM(source code management) gitlab/github/bitbucket,

then the code will be sent to build automation tool to convert code into executable files (Python – pybuilder, microsoft – msbuild, java – jar), so we use Maven with JUnit dependencies,

so then the code will be sent to an automation testing tool for testing purpose, so we uses Selenium,
then we will want to test, so we will make the executables as an image, this requires Docker, for containerization (this is a microservices - api) (container is a like virtual machine except that it is a process utilizing the host OS resources such as kernel),

then we will send the results to the developer back by email.


CONTINUOUS DELIVERY – CD [THIS IS MANUAL]

(if moving application into production that needs manual approval)

CONTINUOUS DEPLOYMENT – CD [THIS IS ALL AUTOMATION, NO MANUAL NEEDED]

(if moving the application into production is automatic process (approval is part of automation process))

Then there will be Configuration Management of the system (where you are developing some solution in a form of script to simplify and manage your configuration (configs means to change the configs to install)). The configuration management tools are such as Ansible, Puppet. If something needs to be installed in the servers, It can install in a matter of minutes to 10000 Virtual Machine System.

Then from ansible, the code will be pushed to Kubernetes to help install images from docker into the various production machines (orchestration).

When you are pushing the code to production, there will be several checks such as UAT (User Acceptance Testing), testing, program manager supervisory. When the program manager give the green light, then you can push the code to production.


CICD GITLAB

In GitLab, to do CICD pipeline in GitLab, there will be a runtime called runner that will help automate the processes. 

in other words, runner is runtime for GitLab for CICD pipeline jobs.

Runner has 2 components:

1. shared runner- via webpage (GitLab Cloud) , needs validation for GitLab account which requires credit card.

2. local runner- need to install runner in local system then you can run your CICD pipeline in local system.


Step-by-Step Basic CICD Pipeline

Step1:-> Create a Private Repo (CICD) in GitLab and add a readMe.md file.

Step2:-> in GitLab (repository tab), create a new branch called dev1 from main branch and add hello.py with print("Hello World") and commit changes.

Step3:-> Create a CICD pipeline (.gitlab-ci.yml) without template.
This is where we write a code so that the hello.py file can run.
the script is:
    job-to-run:
        script:
            - python hello.py
click commit changes




Step4:-> Go to Pipeline tab (needs to be validated first - credit card required) and click on job-to-run.

Step5:-> Merge from dev1 branch to Main branch (when you do this, it will auto run the pipeline job in the main branch also)

Step6:-> clone it into local repo (ubuntu VM).
            git clone #SSH
            #cicd folder will be created

Step7:-> create Maven Project
            mvn archetype:generate
            #mycicdproj folder will be created
            cp * -r /home/vagrant/cicd
            #copy contents of mycicdproj into cicd

Step8:-> push back cicd to GitLab
            git push origin main
            #check GitLab, it will be added AND the CICD will also run another job because it is updated.
            #see that in stage, it is in test.

Step9:-> update the .gitlab-ci.yml to have the maven code
            Job-to-run:

            Script:

            -apt update

            -apt install maven -y

-mvn clean package



GitLab - CICD Pipeline Basic Example

Git lab has 5 stages.

1. .pre (always runs at the beginning of CICD)

2. build

3. test (Default stage)

4. deploy

5. .post(always runs at the end of CI/CD)

Example1 To Run the sequential jobs using stages (stages are defined).

stages:
  - build
  - test
  - deploy

build:
    stage: build
    script: 
        - echo "Build Stage"
test:
    stage: test
    script:
        - echo "Test Stage"        
deploy:
    stage: deploy
    script:
        - echo "Deploy Stage" 

Example2 :-Run the parallel jobs for the stage test. There is a new job newtest is introduced, when you run this pipeline script then you can see that there are 2 parallel jobs running in the test stage.

stages:
  - build
  - test
  - deploy
build:
    stage: build
    script: 
        - echo "Build Stage"
test:
    stage: test

    script:
        - echo "Test Stage"        
newtest:
    stage: test

    script:
        - echo "parallel run Stage"          
deploy:
    stage: deploy
    script:
        - echo "Deploy Stage"   

Example 3:- Executing the jobs in default order (stages are not defined).

prejob:
    stage: .pre
    script:
        - echo "prestage"
build:
    stage: build
    script: 
        - echo "Build Stage"
test:
    stage: test
    script:
        - echo "Test Stage"        
       
deploy:
    stage: deploy
    script:
        - echo "Deploy Stage"        
postjob:
    stage: .post
    script:
        - echo "post Stage"

Example 4:- Run the jobs in the defined order in stages section.

stages:
    - test
    - deploy
    - build

prejob:
    stage: .pre
    script:
        - echo "prestage"
build:

    stage: build
    script: 
        - echo "Build Stage"
test:
    stage: test
    script:
        - echo "Test Stage"        
       
deploy:
    stage: deploy
    script:
        - echo "Deploy Stage"        
postjob:
    stage: .post
    script:
        - echo "post Stage"

Output for Example 4:


Note:-
if you forget to define the stage in stages section and use in the job then it will throw the error as per image below:



Run a Job on a particular Shared runner 

https://gitlab.com/ifanrahman/cicd/-/settings/ci_cd

Run a shared runner there are around 42 runners supported

Step1:-> go to .gitlab-ci.yml and edit using these codes below:

windows-job:

  tags:

    - windows

  script:

    - systeminfo


No comments:

Post a Comment

Fluentd

Open-source log data collector > why logs? - for compliance (auditing, company, business) - for security (transparency, monitoring, admin...