GIT Vs SVN

a) GIT is a distributed version control system while SVN is a centralized version control system.

With Git, each user has a complete copy of the repository data stored locally. Hence, making access to file history extremely fast, as well as allowing full functionality event when disconnected from the network. It also means every user has a complete backup of the repository. Hence, If any user repository is lost due to system failure, then only the changes which were unique to that repository are lost. If users frequently push and fetch changes with each other, then this tends to be a small amount of loss.

With SVN, only the central repository has the complete history. This means that users must communicate over the network with the central repository to obtain history about a file. Backups must be maintained independently by normal copy/paste of the source code. If the central repository is lost due to system failure it must be restored from backup and changes since that last backup are likely to be lost.

- Git repo is created locally on your machine, not a central hub and spoke model like SVN

- Since the repository is local, it’s faster than network based operations

- Easier to work offline

- History and revert is faster and can be done offline

- Each working copy is a branch

- Merges are tracked more closely, happens more frequently

b) Git is extremely fast as compared to SVN because all operations (except for push and pull/fetch) are local. There is no network latency involved for doing following tasks:
1) Perform a diff.
2) View file history.
3) Commit changes.
4) Merge branches.
5) Obtain any other revision of a file.
6) Switch branches.

c) GIT repository and working directory sizes are extremely small as compared to SVN. An SVN working directory always contains two copies of each file, one for the user for work and another hidden in .svn/ to support operations such as status, diff and commit. While a GIT working directory(.git/) requires only one small index file that stores about 100 bytes of data per file.

d) GIT does not have a global revision no. like SVN do.

SVN assigns revision numbers sequentially (starting from 1). Since the revision number is global to the entire repository(including all branches) with SVN, there is still a question of which branch the revision number corresponds to. The last committed revision makes it possible to determine which branch was used.

GIT uses a SHA1(40 character hexadecimal string) to uniquely identify a commit each specific revision. This string identifies the revision as well as the branch it came from.

e) SVN’s revision numbers(starting from 1) are predictable while GIT’s not. Hence, you can easily perform actions related to revisions easily. But with GIT, similar actions requires looking at the log.

f) With SVN, you can check out just a sub-directory of a repository. This is not possible with Git.

- Git is primarily command line, not many visual tools exist (yet) for Git

- SVN’s single repository makes it easier to know you have everything

- SVN having one central repo makes it easier to backup

- The distributed nature of Git makes it more difficult to enforce security on a codebase. This may not be a problem for many open source projects, but may be a problem for some commercial software companies.

- Git uses a SHA1 40 char hex string to identify revisions, it’s also possible to give a revision a shorter name (tag) if needed

keyboard sequence for un hiding excel sheets

keyboard sequence Alt > H > O > U > H + Enter.

Release Preparation and planning

Release Preparation- Release Management

When Release Manager plans the entire releases and activities during the initiation, he or she always think of the release preparation, how to coordinate the release? how to implement the release? Where he will get the resource?When the testing will be done and many more facts come out during the preparation. But he or she should  always keeps few points in mind.

1.1     Gather Resources

Deployment Plan- When the Release Manager plan the release takes the confirmation from the implementation team of a particular deployment that all of the resources needed to successfully deploy the release into production can be accessed. As before, resources in this context include equipment and materials as well as the individuals or groups that will carry out the tasks and activities listed on the deployment plan.

Ensure Change Management approved- Release Manager ensures that change management is approved before roll-out. It may be possibility that change manager needs to approve multiple changes in the same releases which release manager needs to ensure.

1.2 Communication of the Releases

Advance communication was sent out- Release Manager should ensure that communication was sent out to the users, stakeholders before the release date, so that everyone should take an appropriate steps if required and also helpful for business.

Proper information in the communication-Exact information should be communicated to users, support staff, and others during the release preparation process. Information like, release plans, dates, details of where to find and sign up for training courses (if required), any pre-requisites or steps that to be followed by the users and where to obtain more detailed information about the release.

1.3     Inform Users about the Release Preparation

Release Managers will inform the users about release preparation and the tentative timelines to deliver the release in the environment. Release Manager will always ensure that the timely status update is shared with the users every time to avoid any escalations.

1.4   Train Support Teams

The Support teams should always be aware about any releases in the environment and they should be trained properly so that their skills and expertise which will be responsible for operating and maintaining a release are critical to its long-term success. For few releases, support staff and administrators already have the skills they need to perform their roles effectively; while for others, it may be appropriate to rely on their ability to develop practical experience in the field. In some cases, however, the use of training courses, workshops, or technical seminars will be necessary for developing the required skills and abilities.
For each new release, the release manager identifies the skills and abilities required to support and maintain it. Having done so, the release manager arranges for a skills gap analysis to be performed on those responsible for carrying out those tasks in order to see if there are any areas that need to be developed or enhanced through training. Note that there may be a need to enhance IT operations skills as well as skills in technical- or product-focused areas.

1.5   Deployment Schedule

Deployment schedule is the important and key factor in entire release and deployment. Release Manager should ensure the dates of deployment and its timelines are well maintained. Also, it is the duty of Release Manager to inform and update all the teams and stakeholders about the dates of the deployment.

These are few quick facts that Release Manager should ensure while preparing the releases. Please follow the upcoming article about the change or deployment preparation.

AUTOMATED DEPLOYMENTS

DEPLOYMENTS

Background

It is of no doubt that Automation in general is going to be the norm – automation of any manual process in any industry. For this post, we are going to narrow down to automation for a software project. There is quite a bit of jargon – CI/CD/CT, devops, continuous delivery and so on. Read this. Anyways, in the CI/CD pipeline , there are many models based on your application architecture, but one most popular out there is containers for eg. docker containers.

Below is a model that I saw in some forums where we can deploy a software change through a series of steps all the way through CI , build a container image, deploy the container image to AWS.

The flow is basically this

• A nodejs application change is pushed to github
• Github post commit hook kicks off a CI jobs that runs in circleci
• circleci runs unit tests and then triggers a build job preconfigured in dockerhub
• Dockerhub reads Dockerfile in root directory of source and builds the container image and then kicks calls a webhook on tutum (now dockercloud), which has a service and node cluster pre-configured
• Docker cloud is already integrated with AWS (credentials are configured) and can pick an AMI , instantiate it, bring up the docker engine on it , then take the previously created container image and start the container on that ec2 instance. Also the service in docker cloud will map a DNS entry so as to be able to access the application on a certain port
• So as you can see, a change in source code triggers a series of automated steps , that ultimately results in that change being deployed to production (i.e. if you use aws as production)

As you can see, all the compute, storage and network is on public cloud – you dint have to think about on-premises at all, which is great to know that we can have  CI/CD pipeline completely in the cloud.

However , what if we already had some pieces in place on-premises that we would want to leverage and NOT have to pay for CircleCI, dockerhub, docker cloud etc.

A common pattern

One of the most common set of tools used in many enterprise organizations that plan to adopt more open source and CI/CD is to use Jenkins, Nexus , Sonarqube etc. combination. So in the above diagram, the below holds.

So let’s see how we can leverage existing infra/platform that we already built and not have to incur extra costs. Specifically how we can leverage Jenkins and Sonatype Nexus.

So we can fork as below and change the overall flow

• circleci -> Jenkins
• dockerhub -> build node builds the container image
• dockerhub -> Nexus 3.0 holds docker repositories
• Docker cloud -> Jenkins deploys to platform of our choice i.e. aws, azure, on-premises, google cloud etc.

Modified Pattern

Jenkins Pipeline

We can use Jenkins pipeline that can be used to achieve the below pattern.

Use Nexus instead of dockerhub

Nexus 3 has support for Docker repos , hence managing a docker image should not be unfamiliar if you knew how to tag, push, pull , build docker images.

How does your existing Jenkins job change ?

If you use jenkins pipeline, that also shows stage views, then this should be relatively easy. The below pipeline script is an example.

stage 'Dev'
node('master') {
 checkout([$class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, extensions: [], submoduleCfg: [], userRemoteConfigs: [[credentialsId: '226656ad-ed4e-4490-aa18-3f87cad77aa4', url: '<SOURCE_URL>']]])
}
stage 'Build & Package'
node('master') {
 input message: '\'Do you want to proceed\'', ok: 'Hell Ya!'
 sh 'docker build --build-arg username=pradeep --build-arg token=ec3ulgkv2mekoqarv4pzytrh2gdiyuuy5fgqsdnns56e3orxngeq -t "myapplication" -f Dockerfile .'
 echo "$NEXUS_REPO"
 sh 'env'
 sh "docker tag rebates-offer-manager:latest ${NEXUS_REPO}/rebates-offer-manager:${env.BUILD_ID}"
 def myval = sh "docker push ${NEXUS_REPO}/rebates-offer-manager:${env.BUILD_ID}"
}
stage 'QA'
node('master') {
 sh "docker pull ${NEXUS_REPO}/rebates-offer-manager:${env.BUILD_ID}"
}
stage name: 'Staging', concurrency: 1
stage name: 'Production', concurrency: 1

• It is assumed that you have basic understanding of Jenkins pipeline (that helps to build awesome pipelines)
• Docker engine and client is installed on Jenkins master (of course if you would like to run it on a build node, replace master with that node dns in the above script)
• So Jenkins master will build and tag the container
• $NEXUS_REPO is passed as string parameter to Jenkins job
• It is assumed that Nexus 3.0 is being used that has support for Docker image formats (The Nexus repository manager 3.0 LTS will be coming out by end of March 2016 as per their forums)
• env.BUILD_ID is the jenkins build number, which we will use to tag the docker image and push to nexus
• Once we have the container image available in the Nexus repo, we can pull that down to any environment (QA, STAGING, PRE-PROD whatever)

A Stage view from Jenkins looks like this.

Summary

So now , we have shifted the “compute” and “storage” to our tools like Jenkins, Nexus in case these are the tools, that you already used in your on-premises data center and hence you can utilize those resources effectively too.

Caveat: The discussion on whether this should be a long term solution to you is left in terms of whether you want to stay on-premises OR go in public cloud OR have a hybrid on both – My take would be to NOT get vendor locked-in and build your systems agnostic and abstracted as much as possible from vendor dependencies — In short that means – we should be able to reconstruct our infra/platform/software using source code

Deployment

We can use Jenkins to deploy the containers to our targeted deployment platforms – aws, azure, rack , on-premises etc.

See Jenkins plugins that integrate with each of the above platforms.

Some helpful links:

Jenkins-ec2 deploy

Jenkins-Azure

Jenkins dockerhub

References://seleniumframework.wordpress.com/2016/03/20/jenkins-nexus-for-micro-service-deployments/ 

Note:This is accumulated just to prepare knowledge base.

Unhide all hidden worksheets by VBA code

The following short VBA code also can help you display all of the hidden sheets at the same time.

1. Hold down the Alt + F11 keys in Excel, and it opens the Microsoft Visual Basic for Applications window.

2. Click Insert > Module, and paste the following macro in the Module Window.

1 2 3 4 5 6 7 8

Sub UnhideAllSheets()     Dim ws As Worksheet       For Each ws In ActiveWorkbook.Worksheets         ws.Visible = xlSheetVisible     Next ws   End Sub

3. Press the F5 key to run this macro. And the hidden sheets will be displayed at once.

Five “Cs” of DevOps

Five “Cs” of DevOps:

• Continuous Integration
• Continuous Testing
• Continuous Deployment
• Continuous Monitoring
• Continuous Feedback