Continuous Integration is becoming very popular today because of its advantages.
Here is introduction of Continuous Integration and Jenkins:
In below video Jenkins Installation is explained.
Jenkins installation with war file as well as service both ways done practically.
Apart from that how to change port number and how to change home directory that is also shown.
Suppose two or more developers are working simultaneously on
a shared file, keeping track of changes and not over riding each other’s
changes is a difficult task always. Version control systems are there to help
you to work easily in a team and maintain history of changes also easily.
There was a time when no VCS even existed. Developers
mutually decided to work on different files so that changes might not be lost
by other’s save. Here developers were habituated to take regular backup also
manually.
Then they started locking a file they were working on, once
lock is released on a particular file other developer can access it and put
lock on that file to access. In order to work on a particular file which locked
by other developer, One has to wait for other to release the lock.
Then CVCS came into market and allowed users to work
simultaneously on files. Centralized version control system used a central server
that kept changes trace and all new code. In case of CVCS, you have to merge
before commit. For example there is a shared file. Two developers working on
same file so both have copied the file into local system at the starting of
day. Now, one developer has done changes and put on server. Then other
developer has also done changes and tries to commit. But he will be blocked.
Because original file was modified by other. So other developer need to take
the file again and merge changes with new file and put the merged file back to
server.
Then innovation came that is “commit before merge”. In the
late 90s DVCS came into market. Distributed version control system has lots of
advantages. Developer can code even after they are disconnected from central
server. Simply Write some code and commit. Here, Branches creation also easy. Directed
Acyclic Graph would be really helpful to understand DVCS.
Directed Acyclic Graph:
This is not very new, you might have already studied.
It’s a graph which have nodes and edges (Lines).And we need
to use directed graph that means edges are directed (they are having arrows for
direction).Look at below image. Its a directed acyclic graph with 3 node and 2
edges connecting to nodes. Node 3 is child of node 2 and node 2 is child of
node 1.If you want to add one more arrow from node 3 to node 1 that is also
fine. But as its directed graph, you can not go in reverse direction. From node
3 to node 2 is possible same way node 3 to node 1 also possible but node 2 to
node 3 not possible because of direction.
Now, here is how DVCS relates to Directed acyclic graph:
·All commits can be
considered as nodes.
·Each and every node will
have detail about parent node.
·Apart from parent node
details, All Nodes will have details of Changes made in a particular commit. So
it means what changes in code you did in this particular commit that was not
there in last commit that details will be traced.
·All nodes will be
identified uniquely with a Hash value. Hash values are calculated According to
the details of Parent node and changes in this commit. It generally uses SHA-1
Algorithm.
·So if you make even a
single change and commit, it’s going to create a new node and new hash value.
In diagram we have simple numbers like 1 2 3 but in real time hash values are
longer.
Workflow for DVCS
Now, for better understanding lets discuss few workflows.
Imagine there is a server which is having 3 commits (nodes).
You are a developer and you want to want in this project. So
you take all existing work from server to your local system. That is also known
as cloning. So now your local system will also have same 3 commits and same
existing code.
Now you stared your work and at the end of day you finished
with some amazing code. So you save and commit the code. As soon as you commit
it will create a new node, which is node 4.it will be child of node 3 and will
have details of what changes you have done.
Server is still having 3 nodes only. So when you push your
changes to server it will check for nodes which are not already there. That is
node 4 which can be easily identified with unique hash value. So changes along
with details of node 4 will be pushed and server and your system will be
synchronized properly.
It was pretty good scenario where you easily merged your
code with existing code on server. Suppose that’s note the case. Some other
developer also working with you.
At the staring you both cloned from server your system, his
system and server all will have same 3 nodes.
Now he has done some changes, committed changes and pushed
to server.He left office and you are still working :(
After some time, you have also completed your work and
committed
In this scenario when you try to push changes to server, you
will have difficulty. Your last commit node 4 is child of node 3. While on
server last node is 5.so 4 cannot be pushed after 5 because it maintains parent
node details also.
So solution is that you need to merge your code with new
node 5 and then only you can push the changes. So first you need to fetch new
changes on your system.
Now your system is having two end nodes, so it will be
confusing for server when you create build. Whether to build according to node
4 or node 5.We need changes of both so we need to merge.
When you merge, it will create a new node that is node 6
which will have 4 and 5 as parent node.
If changes in 4 and 5 are not in conflict, merge
would happen automatically but if there
are conflict in changes, you need to decide how to merge.
So once you have merged, you need to push changes to server.
So after that server will have changes of both developers and any work will not
be lost.
In case of CVCS,we would do changes on exiting node only
that is node 4 , but in the case of DVCS, we will create a new node that is
node 6.So that and changes are not lost and will be kept in history for future
reference.
After Version control system and workflows let’s talk about
GIT
GIT is an Open source version control System. This keeps
track of changes done in code.
With the help of GIT you can easily and very efficiently
collaborate with team and don’t mess up the code. GIT keeps track of changes
only.
Take one photograph of your code, after some take another
photograph and compares both. Suppose your code is having 100 lines of code at
a time, And after some there few more lines
are added and now there are 125 lines of code. It will not store your
code but it will keep trace of change only. That is 25 new lines added. But
remember it’s not backup system its version control system.
There is a word in GIT Terminology: Repository. It’s the
place where you store your code. For example your project folder in your system
or it can be repository on GitHub.
In your repository any type of code file can be there, Say
foo.java. Now, whenever you create a new file in repository by default it will
not be traced. You need to add to Staging area in order to trace changes. So
all your files that you want to trace, will be added to staging area then only
changes will be noticed. When you do a commit, only changes (update or new
file) that are present in staging are they will be commited,other changes will
not be commited.Once a file is traced, It can have two states : modified and
unmodified. If you have done any change since last commit, it means file is
modified. Otherwise it’s not modified. In summary, all files in repository will
have three state: untracked, tracked and not modified, tracked and modified.
When you commit, only modified traced changes will be committed.
