Webhook for Jenkins and github

One of the functions to link GitHub and Jenkins is called “Webhook”. By using this Webhook, you can run Jenkins’ jobs when pushing a branch to the repository managed on GitHub, when creating a new Pull Request, and so on.

There are three main ways to link Jenkins with GitHub and Webhook by the following three methods.

Jenkins Standard Webhook
– Set up “build for remote” provided as standard function of Jenkins
Git Plugin
– A plugin that can provide functions that can clone and execute git repositories when building Jenkins GitHub Plugin.
Plug-in to receive push event from GitHub
– Jenkins can automatically register Webhook to GitHub

Jenkins Standard Webhook
Build and trigger

Continue to configure Webhook with GitHub. From the repository page you can add it from Setting > Webhooks > Add Webhook.

Go to Github repository

See webhooks and add webhook

Jenkins
「Jenkinsの管理」>「ユーザーの管理」>「(API Token を取得したいユーザーID)」>「設定」>「APIトークンの表示」

Payload URL
http://[USER_ID]:[API_TOKEN]@[JENKINS_HOST]/job/[JOB_NAME]/[build|buildWithParameters]?token=[TOKEN_NAME]

Oh, Ok.
close jenkins
[vagrant@localhost app]$ sudo service jenkins stop
Shutting down Jenkins [ OK ]

Jenkins setting and how to use it?

Job
Job describes a series of operations that Jenkins wants to run. If you think that is something like batch files or Linux shell script now.

1. put name for Enter an item and press free style project build

2. Next page, chose build and set shell execution

3. write shell script

echo 'hello jenkins'

4. save task and run build

console output

ユーザーhpscriptが実行
ビルドします。 ワークスペース: /var/lib/jenkins/workspace/HelloJenkins
[HelloJenkins] $ /bin/sh -xe /tmp/jenkins6861841405666017940.sh
+ echo ‘hello jenkins’
hello jenkins
Finished: SUCCESS

Wow, Perhaps it’s fun to play.

install Jenkins into CentOS

First make sure java is installed
[vagrant@localhost app]$ java -version
openjdk version “1.8.0_191”
OpenJDK Runtime Environment (build 1.8.0_191-b12)
OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)

Add jenkins repository
[vagrant@localhost app]$ sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo
–2019-01-22 21:14:32– http://pkg.jenkins-ci.org/redhat/jenkins.repo
pkg.jenkins-ci.org をDNSに問いあわせています… 52.202.51.185
pkg.jenkins-ci.org|52.202.51.185|:80 に接続しています… 接続しました。
HTTP による接続要求を送信しました、応答を待っています… 200 OK
長さ: 71
`/etc/yum.repos.d/jenkins.repo’ に保存中

100%[======================================>] 71 –.-K/s 時間 0s

2019-01-22 21:14:36 (3.39 MB/s) – `/etc/yum.repos.d/jenkins.repo’ へ保存完了 [71/71]

[vagrant@localhost app]$ sudo rpm –import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key

install jenkins
[vagrant@localhost app]$ sudo yum install -y jenkins


[vagrant@localhost app]$ sudo service jenkins start
Starting Jenkins [ OK ]

wow

Jenkins vs TravisCI vs CircleCI

CI stands for Continuous Integration. In CI(Continuous Integration), developers frequently merge their code changes into the central repository and run automated builds and test each time.

I would like to compare popular CI tools.
– Jenkins
– TravisCI
– CircleCI

1. Jenkins
As a feature of Jenkins, it is highly scalable, it can do whatever you can customize, and build on on-premise.
Although it was a popular CI tool with abudant articles, since it is necessary to prepare a server for CI, maintenance and operation of that server becomes necessary.
– To incorporate it into the workflow including actual production, introduction needs to be done systematically.
– Failure to manage will take cost consuming.

2. TravisCI
Since it is cloud, there is no need to manage and operate the server.
Increased compatibility with Github
Abundant article
It is difficult to debug because SSH does not put it in a container
Since it is cloud, ip changes every time it builds

3. CircleCI
Since it is cloud, there is no need to manage and operate the server.
Support is strong
Abundant article
Since it is put in a container with ssh, it is easy to debug
You can start using it for free
Recently the version has gone up and it corresponds to docker and workflow
Because it is Cloud, every time it builds IP changes.

Display the uploaded image on Laravel 5.7

Create a file name and move it from the temporary folder to under item. Pass variable of file name from controller to view.
ImageIndexController.php

class ImageIndexController extends Controller
{
    public function index(){
    	return view('imageindex');
    }

    public function store(Request $request){

        $filename = date("YmdHis") . "." . $request->file('image')->guessExtension();
    	$request->file('image')->move(public_path('item'), $filename);
    	return view('imageindex',compact('filename'));
    }
}

If there is a variable in the “If statement”, display it.
imageindex.blade.php

@if(!empty($filename))
      <img src="/item/{{$filename}}">
      @else
      @endif

1. upload the image and put register button

2. Then image is displayed on view page.

Ok, first step is well done.
I think I need to insert a file pass to mysql.

/dev/null 2>&1

#/bin/bash

echo "this is standard output"

[vagrant@localhost app]$ ./echo.sh
-bash: ./echo.sh: /bin/sh^M: bad interpreter: そのようなファイルやディレクトリはありません
[vagrant@localhost app]$ sed -i ‘s/\r//’ echo.sh
[vagrant@localhost app]$ ./echo.sh
this is standard output

It took an hour to come here.

If it is executed normally, it will be displayed on the standard output, but if you redirect it, it will be able to output to another location.

When redirecting to standard error output
[vagrant@localhost app]$ ./echo.sh >&2
this is standard output

When redirecting to standard output
[vagrant@localhost app]$ ./echo.sh >&1
this is standard output

[vagrant@localhost app]$ ./echo.sh > /dev/null
/dev/null is a unix special file, it is an empty file.

Merging standard error output to standard output
2>&1

somehow I got it.

What is RFP(Request For Proposal)?

RFP is a document that asks the vendor candidate to make a concrete proposal when introducing an information system or outsourcing it. Describe the purpose and overview of the system, requirements and constraints.

A concrete RFP method is easy to create when considering the overall configuration into the following three categories.

1. Overall picture
It is intended to make it simple to understand the whole system development that we would like to request the proposal this time.
Describe development objectives, goals, budget, schedule and so on.

2. Proposed requirements
Specifically, it shows specifically what you want a suggestion that meets.Describe the scope you want the suggestion, the division of roles, required functions, operation / maintenance, deliverables.

3. Other
Information that seems better to convey to other than 1 and 2, what you are astray about judgement, etc. are listed as supplements.

1. overall picture
background of development
purpose of development
goals / achievements
budget size
schedule
target
number of contents to be handle

2. proposed requirements
scope to request suggestion
delivery deliverables
method of system development
functional requirement
operation and maintenance requirements
education and training requirements
organization
structure

3. other
consideration
assumed competing site

What is Blue / Green deployment?

Systems that take a method called Blue/Green deployment have increased.

In place: Reflect only the new revision application on the spot, leaving the instance intact.
Blue / Green: Build and replace a new instance for new revision applications.

And it can roughly classify the following three categories at the reflection speed with another axis different from the realization method.

All at once: Deploy all of them all at once with new revisions.
One by one: Deploy a new revision one by one.
Batch: Deploy a few new revisions(eg half)

There are people often thinking about Blue/Green deployment “only new instances of the revision are constructed by switching to the same number as it is now”, but this kind of deployment method is also called Red/Black deployment in recent years. This is just one way of “deployment at all at once in Blue/Green”

In place
– Merit
Since this method does not require additional instances at deployment, it is very effective in environments where it is not easy to create instances such as on-premises environments. Since it is enough to distribute only the application and restart or the like to the instance where hardware purchase, OS installation and various settings have already been completed, additional instance costs are not required at high speed.

– Demerit
One is tat remote operation is required. Remote operation is to operate on an instance that is running by way of ssh etc. In the case of using ssh, it is necessary to manage the key, so the construction of the instance becomes somewhat complicated, and the risk of opening a hole such as ssh etc. for the instance used in the production environment is reduced as much as possible from the very beginning it is safer to have it. Although we can alleviate this somewhat by using an agent type mechanism like AWS CodeDeploy, we do not change the risk of distributing files or executing arbitrary commands during operation.
Finally it is also difficult to roll back. Consistency is more likely to collapse when returning things that have changed once. “In Place”, there is the fact that you have to maintain two types of deployment, “deploy application” and “deploy under application”.

Blue/Green
Blue/Green is not necessarily just switching before preparing the same scale in Blue/Green. The point is that it does not do anything for running, it creates a new revision on another instance and switches over the whole green/blue according to an arbitrary strategy.

– Merit
You can eliminate all the disadvantages of in place mentioned above. First of all, for remote operation, we do not make any changes to the running instance at deployment, so we do not need anything. Instances need not have any mechanisms related to deployment. This also simplifies the application development process.

Regarding consistency, if you create an instance image (Amazon Machine Image(AMI) for Amazon EC2) for each deployment as an extreme way of way of making it, you can guarantee that instances of the same revision are of exactly the same configuration. This is the method that Netflix is taking.

Rollback is very easy. Because Blue does not have any changes in deployment, you simply need to return traffic to Blue. Even after discarding Blue, restoration is also easy if you restart it from AMI of the past revision.

As described above, in Blue/Green deployment is carried out together with “deployment of application” with lower deployment, so for example, it is possible to realize OS updates and the like with exactly the same mechanism, the deployment process becomes one and maintenance also will be much easier.

– Demerit
For example, it is said that cost is high for making AMI for each deployment. Especially it takes time to rebuild from AMI when deploying minor fixes. This can be avoided to some extent by automating the creation of AMI and configuring a CI / CD pipeline that is already ready for deployment. Rather than creating an AMI for each deployemnt, you can keep the AMI of the basic configuration fixed so that you get the latest revision at instance startup, but in that case a breakdown of consistency similar to “In place” care should be taken as it can happen.

Also typically said is the cost of having to make extra instances. Although you wan to make a bit of modification you have to bother to set up an instance, trying all at once will double the cost temporarily, and that is certainly a waste.

Think about development quotation

development quotation
– Implementation
– Additional man-day or man-hour
– Unit Test
– Source Review
– Combined Test
– Release man-day
– Procedure preparation

Difference between external design and internal design
– external design
— system function, performance, condition
– internal design
— operation, function, physical data inside the system