DevOps part 4, JUnit(or other) Automation (Individual)

--Originally published at Fernando Partida's Blog

This DevOps assignment is probably the most compicated of them all as it was a culmination of everything done in the previous DevOps. First of all I used pyTest as my unit testing tool as it was the easiest to install and use in my virtual machine. Then for all the gitHub stuff I used my pytesting-Quality repository.

First I created a script in python that creates a local webserver that reads the index.html file located at my scripts root folder. This file is constanly overwritten, and the code for the server is the following:

import http.server
import socketserver

PORT = 8080
Handler = http.server.SimpleHTTPRequestHandler

with socketserver.TCPServer(("", PORT), Handler) as httpd:
    httpd.serve_forever()

Then I created another python string in charge of testing the pytest_test.py file and seeing if it throws a “.” if the test succeeds or “F” if it fails. Then it updates the index.html file, with the status of the test. After doing so, the program updates the README.md file according to the status. Finally the script adds, commits with message and pushes the pytest_test.py and README.md files. The following is the code for doing so:

import subprocess

c = subprocess.check_output('pytest ~/PycharmProjects/pytest_test/pytest_test.py |grep "pytest_test.py "', shell=True)

s = c.split(b' ')[1].decode("utf-8")

if (s=="."):
        subprocess.call('echo "pytest test passed" > index.html', shell=True)
        subprocess.call('echo "# pytest test passed" > ~/PycharmProjects/pytest_test/README.md', shell=True)
        subprocess.call('git -C ~/PycharmProjects/pytest_test add pytest_test.py',shell=True)
        subprocess.call('git -C ~/PycharmProjects/pytest_test commit -m "pytest_test updated"', shell=True)
        subprocess.call('git -C ~/PycharmProjects/pytest_test add README.md', shell=True)
        subprocess.call('git -C ~/PycharmProjects/pytest_test commit -m "README.md updated"', shell=True)
        subprocess.call('git -C ~/PycharmProjects/pytest_test push origin master', shell=True)
else :
        subprocess.call('echo "pytest test failed" > index.html', shell=True)
        subprocess.call('echo "# pytest test failed" > ~/PycharmProjects/pytest_test/README.md', shell=True)
        subprocess.call('git -C ~/PycharmProjects/pytest_test add pytest_test.py',shell=True)
        subprocess.call('git -C ~/PycharmProjects/pytest_test commit -m "pytest_test updated"', shell=True)
        subprocess.call('git -C ~/PycharmProjects/pytest_test add README.md', shell=True)
        subprocess.call('git -C ~/PycharmProjects/pytest_test commit -m "README.md updated"', shell=True)
        subprocess.call('git -C ~/PycharmProjects/pytest_test push origin master', shell=True)

Now finally for the pièce de résistance the crontab file was updated so that it runs the server continuously, and the tester on every pc reeboot. The following is teh code obtained from running the sudo crontab -l command.

# Edit this file to introduce tasks to be run by cron.
# 
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
# 
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').# 
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
# 
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
# 
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
# 
# For more information see the manual pages of crontab(5) and cron(8)
# 
# m h  dom mon dow   command
* * * * * /usr/bin/python3 /home/ferpart/Documents/Scripts/server.py
@reboot /usr/bin/python3 /home/ferpart/Documents/Scripts/gitPusher.py

The following is a GIF showing everything working. (Obviously not using crontab at the moment, as it wouldn’t update that quickly).

DevOps part 4, JUnit(or other) Automation (Individual)

Week 9 Practical – Python Unit Testing (Individual)

--Originally published at Fernando Partida's Blog

For the first part of this assignment we were tasked with reading Simple Smalltalk Testing: With Patterns and posting a Hypothes.is annotation and the following is evidence of that.

Week 9 Practical – Python Unit Testing (Individual)

Now for the WayBackMachine it is a website that allows the user to see versions of a website for the past basically. This allows us to see how something used to look some years ago. For the following I used the Amazon website from the year 2006 and this was the result:

Week 9 Practical – Python Unit Testing (Individual)

We were also assigned for doing a course on Unit Testing and Test Driven Development in Python the following is evidence of pytest running on pyCharm:

Week 9 Practical – Python Unit Testing (Individual)

The course was a bit longer than I had expected, and got bored at many times, but it did allow me to learn how to start using unit testing for something different than java (in this case python). Something I did find quite interesting was the section about best practices. That is because learning how to do testing in the most “correct” way helps others and yourself in the future understand what you’re doing.

DevOps part 3, GitHub, SSH and keys (Individual)

--Originally published at Fernando Partida's Blog

For this week we were assigned to use 2-factor authentication and ssh for our github profiles. Fortunately or unfortunately (in context of this practice) I had already done the previous, so not much can be written about the previous task.I will of course insert an image to prove the previous.

DevOps part 3, GitHub, SSH and keys (Individual)

As for the automation i will be automating the pull of the following repository:

Advanced Programming GitHub

This is the code used for the automatic pull (note that the server automation used for the previous DevOps assignment has been removed)

# Edit this file to introduce tasks to be run by cron.                          
#                                                                               
# Each task to run has to be defined through a single line                      
# indicating with different fields when the task will be run                    
# and what command to run for the task                                          
#                                                                               
# To define the time you can provide concrete values for                        
# minute (m), hour (h), day of month (dom), month (mon),                        
# and day of week (dow) or use '*' in these fields (for 'any').#                
# Notice that tasks will be started based on the cron's system                  
# daemon's notion of time and timezones.                                        
#                                                                               
# Output of the crontab jobs (including errors) is sent through                 
# email to the user the crontab file belongs to (unless redirected).            
#                                                                               
# For example, you can run a backup of all your user accounts                   
# at 5 a.m every week with:                                                     
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/                               
#                                                                               
# For more information see the manual pages of crontab(5) and cron(8)           
#                                                                               
# m h  dom mon dow   command                                                    
0 18 * 1-6 1 /usr/bin/git pull origin master /home/ferpart/Documents/Code/gitClones/gitAPobed

The previous script that was added to the crontab, will pull from the aforementioned GitHub repository every Tuesday at 7:00 pm (or 19:00) for the rest of the semester which is the time at which the class is taken every week. A thing to note is that i wrote the time as 18 instead of 19 because the time value starts at 0.

DevOps part 2, Linux Server Setup (Individual)

--Originally published at Fernando Partida's Blog

For part 2 of DevOps we were assigned to install a linux distribution, run a server, and use crontab to schedule execution.

The linux distribution that i chose to use is that of Ubuntu 18.10 because i already had it installed as a virtual machine.

DevOps part 2, Linux Server Setup (Individual)

For setting up the server I installed nodejs with the following command:

sudo apt install nodejs

With nodejs installed, a script for running the server was created at a folder designated for testing. The script written was the following:

const http = require("http");
const hostname = "127.0.0.1";
const port = 8080;

const server = http.createServer((req, res) = >{
        res.statusCode = 200;
        res.setHeader("Content-Type", "text/plain");
        res.end("Server testn");
});
server.listen(port, hostname, () = > {
        console.log("El servidor esta corriendo");
});

For testing the following bash command can be run:

node test_server.js

This will show us the following screen:

DevOps part 2, Linux Server Setup (Individual)

After that it was just question of sheduling it to run. For now i set it for running 24/7, 365 for testing with the following code:

First to enter crontab the following command was run:

sudo crontab -e

Then the script used was the following

# Edit this file to introduce tasks to be run by cron.                          
#                                                                               
# Each task to run has to be defined through a single line                      
# indicating with different fields when the task will be run                    
# and what command to run for the task                                          
#                                                                               
# To define the time you can provide concrete values for                        
# minute (m), hour (h), day of month (dom), month (mon),                        
# and day of week (dow) or use '*' in these fields (for 'any').#                
# Notice that tasks will be started based on the cron's system                  
# daemon's notion of time and timezones.                                        
#                                                                               
# Output of the crontab jobs (including errors) is sent through                 
# email to the user the crontab file belongs to (unless redirected).            
#                                                                               
# For example, you can run a backup of all your user accounts                   
# at 5 a.m every week with:                                                     
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/                               
#                                                                               
# For more information see the manual pages of crontab(5) and cron(8)           
#                                                                               
# m h  dom mon dow   command                                                    
* * * * * /usr/bin/node /home/ferpart/Documents/Code/DevOps/test_server.js

Asterisks were used so that it runns all the time.

Intro to DevOps (Individual plus peer review)

--Originally published at Fernando Partida's Blog

DevOps as its name states is short for “Development Operations”. This is a term that started from the combination of the agile operations and that which is the collaboration between the development and operation staff on all stages of the development cycle.

In general its described as stated before “it is a collaboration of the developer and operations”. The following are the generally known levels of a DevOps structure.

  • DevOps Values: These are fundamentally the same as those seen within the agile methodology. Just with slight tweaks focused on the service delivered to the customer.
  • DevOps Principles: One of the most commonly cited principles is that of “Infrastructure as code” otherwise, no other general principles have been agreed collectively upon.
  • DevOps Methods: Methods for implementation are generally the same as with other methodologies. these could be “scrum”, “kanban”, etc…
  • DevOps Practices: The most important practices is that of continuous integration and continuous development.
  • DevOps Tools: Tools that could be used are vast, but these are some examples; “configuration management”, “orchestration”, “monitoring”, “virtualization and containerization”, etc…

In general we can then understand that even though DevOps is a very good, versatile and easy to use tool, It is not very easily defined.

 

Secret Life of Bugs (Individual)

--Originally published at Fernando Partida's Blog

I enjoyed reading the secret life of bugs paper. Even though it was a bit on the long side it had analogies that made everything easier to understand. It gave the reader a way to understand and analyze where it is that software “bugs” come from. The paper also gave a overview of how it is that bugs are commonly found, observed, and finally corrected.

Unit Tests (Individual)

--Originally published at Fernando Partida's Blog

For unit testing i decided to go with Eclipses’ included Junit 5 for testing. The library is now added in my project, and it can be used in the case of the implementation i used by importing the Junit.assert.asserequals function to check if a message is displayed correctly.

The following is a list about how to go on with writing on junit 5 https://junit.org/junit5/docs/current/user-guide/#writing-tests

My github repository that’ll be used for the class is the following aswell:

https://github.com/ferpart/SoftwareQualityandTesting

Kent Beck Audio

--Originally published at Fernando Partida's Blog

The following is a review of a podcast done by “Scott Hanselman” on collaboration with “Kent Beck”. This is my interpretation and reflection of what i thought was interesting in the interview heard on the podcast.

Although the podcast was a bit longer than i had expected in the beginning it was quite satisfactory to listen to (although a bit heavy). As someone who never ever heard or read much about Kent Beck beforehand, listening to him about ho he talked about how he enjoyed making “nerds” feel more comfortable.

Kent Beck talks about testing and committing/reverting changes which is a theme that interested me a lot as i have been through this. What I meant previously refers means that the programmer updates a lot of code, and when it fails whilst testing all changes are reverted and everything is lost. I enjoyed hearing about the “test, commit, revert” workflow, in which not so much work is destroyed because it es made in a way so that a programmer only makes small changes before testing, leading to much less destruction of code and ideas.

In general i thoroughly enjoyed the podcast and even though i didn’t quire learn anything new it was pleasing to hear alternatives to the way I’ve been working so far.

Week 3 update

--Originally published at Fernando Partida's Blog

As we continue learning from the “Mobile device application development” course, we are planning how we are going to go about the development of the project.

The topics covered this week were all about changing activities/views and the general usage of databases. As such we are currently researching the appropriate database that will be needed for storing the intended data our users will be providing. As of right now, because of ease of use and because it is the database well be using for the general class will be SQLite. If a change is needed or a different database is selected for the project, said change will be documented in a future blog update.

Week 2 Update

--Originally published at Fernando Partida's Blog

Stated in the general plan, this weeks team assignment was to investigate connectivity with the api’s of all of the websites we’re thinking of linking for the application.

The investigation about the general workings of the api’s has been done, and assuming the documentation in all the websites is correct, we shouldn’t have an issue in developing the envisioned project.

What the previous paragraph sums up  is that the progress is going according to plan, and the research has been done. Whats left is to test if everything works accordingly.