Showing posts with label cicd. Show all posts
Showing posts with label cicd. Show all posts

Sunday, January 12, 2020

Episode #18 – The journey of 1000 miles starts with a single step ...... Unit Testing


Date: 1/12/2020
Guests: none

Welcome and greetings

Recap of last episode
  • In the last episode, we discussed Test Automation and how it can be used to accelerate your pipelines. We also discussed some of the methods of automating tests and some products that can help you with your automation.

Summary of this episode
  • In this episode, I’m going to discuss the lowest level of testing possible by a developer, and that is Unit Testing. I’m going to give a brief description of what it is, what value or benefits that it can bring to the table, when to start it, and some examples of how it can be implemented.

What’s in it for you?
  • After listening to this episode, you should have a better understanding of what unit testing is, how it is different from other types of testing and how it can be used to speed up some of your development efforts.

Episode Content

  • What is it?
    • Unit Testing is when a developer writes tests to validate the smallest piece of code possible.
      • Methods, functions, procedure calls, etc.
    • A Unit is a self contained piece of code that typically has a small number of inputs and outputs.
    • A Unit Test can have constructor and destructor methods to ensure that any needed data or structures are created before the test is run and cleaned up once the test is done.
  • What benefits does it provide?
    • Testing smaller pieces of code is faster than testing the whole program.
    • Tests are simpler since they cover a smaller set of code.
    • Defects found in unit testing are cheaper to fix since the change should be smaller.
    • Debugging defects found in unit testing is faster due to the smaller set of code to review.
  • When should I start using it?
    • When you write the first method, function, procedure call.
    • You should write your unit test cases in tandem with your program code.
    • The earlier the better.
    • It is one of the predecessors of Test Driven Development.
  • What can it be used with?
    • Any of the modern programming languages should have their respective unit testing framework. Java has Junit, c variants have xunit, python has pytest…..you get the picture.

  • How to use it? A real life example for Java (kind of)
    • method call

public int addNumber(int x, int y) {
return x+ y;
}

    • Unit test

public void testAddNumber() {
double result = addNumber(2,3);
assertTrue(result == 5)
}

    • Unit Tests are grouped into TestSuites
    • Test Suites are executed by TestRunners
    • Test Suites are classes that contain a grouping of individual Unit Tests that relate to a specific Java class that you are developing.
    • TestRunners are classes that are written to consume the Test Suites, execute any test cases found in the TestSuite class, and raise the result for the entire run of the TestSuite.
  • There are several different types of frameworks, Junix, xunit, pytest, mockito.
    • You should choose the one that is appropriate for the program that you are developing.
  • Each framework while similar, has its own syntax and procedures.
  • How to get the most out of your Unit Testing?
    • Pick the framework that is designed for the language that you are working with.
    • Keep the test unit as small as possible (single method or function).
    • Run your Unit Tests often – faster feedback is better.
    • Update your Unit Test Cases as changes are made to your codebase. Don’t wait until the end to write new Unit Tests or update existing ones.

Recap of this episode
  • In this episode, I discussed unit testing, how it benefits developers and development efforts, and examples of how it can be implemented.


Like me Like my podcast – share, like, thumbs-up, review, subscribe

Next Episode: Family Feud - Component Integration Testing

Monday, December 23, 2019

Episode #12 - Ball and Chain of Custody - Legal Requirements



Last Episode recap
  • In the last episode we discussed Jenkins. We talked about what it is, what it is not and how it can be configured to use in your automation efforts.

Summary of this episode
  • I hope you have seen that I’m trying to do these episodes in what I think is a very specific order. We will build on each episode so that you understand how each topic discussed can be used to enhance your automation effort.
  • In this episode, we will discuss maintaining a software “chain of custody”, why it is important, what happens if you don’t and how your automation can help you do it.

What's in it for you
  • A better understanding of the importance of maintaining good software controls and how it keeps you and your company out of trouble.

Episode Content:
  • Why does it matter?
    • In 2001, a large corporation named Enron was embroiled in a controversy involving its financial records. It was followed by other controversies with other large publicly traded corporations.
    • In July of 2002, two U.S. Congressmen, Sen. Paul S. Sarbanes and Sen. Michael G. Oxley, sponsored a bill to rein in the fraudulent financial reporting that led to these massive corruption scandals. This bill was titled the Sarbanes-Oxley Corporate Responsibility Act of 2002 (or SOX for short).
    • The bill tightened controls around how a company recorded and reported its financial Information.
    • One of its goals was to provide for structured, consistent and repeatable controls.
    • It was created as a way to for the leaders and employees of a company to create and maintain a culture of corporate financial responsibility.
    • It provided for the officers of a company to “sign” their financial statements. This means that they take personal responsibility that they are accurate and correct with no malfeasance or attempts at fraud against investors.
    • It increased the fines and sentences for individuals that attempt to commit fraud or illegal financial practices.
    • It requires a company to document its internal control processes.
    • It requires a company to to have an external auditor to certify that their internal control processes are being followed and that the financials are accurate.
    • It dictates that all off-balance sheet transactions must be reported.
    • It provides the Security and Exchange Commission more power to perform investigate any company suspected of violations.

  • Who has to comply?
    • All publicly traded companies
    • All subsidiaries of foreign companies in the U.S.
    • All private companies that are preparing for an IPO
  • Fines and Prison Time
    • Non-compliance could result in fines up to $1 million dollars and up to 10 years in jail
    • If a company intentionally defrauds investors, it could result in $5 million dollars in fines and up to 20 years in jail.

  • When should you worry about it?
    • You shouldn’t worry about it too much but,
    • You should make sure that your control processes are well documented, your staff understands why they are in place, and any consequences that they or the company might face if they do not follow the controls.
  • Where should they be implemented in your SDLC?
    • In my opinion, every step of the SDLC, for example:
      • Requirements – should be documented and changes should be tracked.
      • Development – All source code should be in an SCM system so that any changes can be tracked back to why and who made the change.
      • Build – All builds should be documented and all artifacts of the build process should be stored and versioned.
      • Testing – all test cases that are used to verify requirement functionality should be documented and any results of those test cases related to a specific build should be tagged with the build ID and archived after completion.
      • Environments – All changes to an environment used for a specific build should be tagged and documented for approval prior to implementation.
      • Deploy – The reason for the deployment, date and time, and approval should all be documented.
      • Promotion to a higher environment – all approvals should be documented and tracked for each environment promotion.


  • How can your automation help you with all this documentation?
    • By using some or all of the tools that we are discussing, you can have a lot of this documentation done for you automatically by your automation.
    • For Example:
      • Requirements: Jira, Quality Center
      • Development: Github, Bitbucket, SVN, Team Foundation Server
      • Build: Maven, Gradle, Jenkins, CI/CD pipelines
      • Testing: qTest, Quality Center, Bugzilla
      • Environments: CI/CD, Jira
      • Deploy: CI/CD, Jenkins, Ansible, Terraform
      • Promotion: Jira, Remedy, ServiceNow

  • Each of these tools will automatically record the changes that you make, builds that run, tests that are performed, and artifacts that are deployed.
  • Using Jenkins or a similar tool, you can create a pipeline or job that can automatically create the files required by your audit partners to run their reviews.
  • Usually the only changes to be reviewed after automation are any changes that are made to the automation pipeline/jobs themselves.
  • Working with internal and external auditors can be a daunting task since they are trained to ask many probing questions to identify problems with your process.
  • Using automation makes their and your job easier when it is time to perform these control reviews, which is usually monthly, quarterly, semi-annually or annually.

recap of this episode
  • In this episode we discussed what software chain of custody is, why it is important, where it originated, how it is controlled, and how your automation can assist you in financial reporting compliance audits.


Next Episode: Artifact repositories



Thursday, December 19, 2019

Episode #11 - Tools - Jenkins - Not your everyday butler



Last Episode recap
  • In the last episode, we discussed CI/CD and related build topics.  We talked about what good CI should look like and what components make up that CI.  We talked about CD and how that is typically done and also dis-jointed or dis-associated CI and CD.

Summary of this episode
  • In this episode, we are going to discuss Jenkins and how it can be used in your automation.

What's in it for you
  • Once you listen to this episode you should have a better understanding of what Jenkins is and how it can be used, the types of tasks that can be automated, and some of the items that can be configured (plugins) to enable automation.

Jenkins description
  • what is it
    • Jenkins is an automation platform that can perform a variety of tasks to enable your automation.  It can be used to run your CI/CD  pipelines integration your SCM to your automation all the way to your production environment.
  • what's it used for
    • build jobs
    • testing jobs
    • deployment jobs
    • reporting jobs
    • auditing jobs
    • monitoring jobs
  • good use cases
  • types of jobs
    • freestyle
    • pipelines
    • multi-branch pipeline
  • plugins
    • examples:  folders, pipelines ( many different plugins ), git, ansible, artifactory, azure app service, credentials, docker, generic webhook, groovy, mask passwords, nexus artifact uploader, SSH plugin, and many more.
    • when are they useful and when should you use them
      • usually when a vendor has an integration plugin and you can’t put it into your pipeline as code
      • or when it is a very specialized piece of functionality that you cannot easily code
    • when should you not use them
      • when you can easily code the functionality in your pipeline code (ssh to another server perform a task)
  • agent nodes
    • accessing agent nodes
    • ssh creds
  • folder security
    • matrix based security
    • LDAP security
  • Integrations
    • SCM
    • others

recap of this episode
  • Description
  • Use cases
  • Job types
  • Plugins
  • Agent Nodes
  • Security
  • Integrations



24 – Tools - Docker

     Date: 6/8/2020 Guests: None Welcome and greetings Recap of last episode In our last episode we contrasted a few different container man...