Google

IT Automation: It’s not that scary!

228 ratings

Course 5 of 6 in the Specialization Google IT Support Professional Certificate

This course is designed to give you an introduction to concepts related to the automatic management of infrastructure in the IT industry. Using tools like scripting languages, version control, configuration management systems, and monitoring solutions, this course will give you an introduction to automation in IT. It will have an emphasis on creating automation that’s both scalable and manageable. By the end of this course, you’ll be able to: - cite the fundamentals of programming using the Ruby language. - create basic automation scripts to perform system administration tasks. - use regular expressions to extract meaning from raw text. - manage code by using the version control system, Git. - develop and understand the benefits of tests for the scripts and automation they create. - deploy software using the Chef configuration management software and understand the principles of configuration management in the IT context. - track the health of technology systems through monitoring and become familiar with common monitoring concepts and practices Before taking this course, it's advised (but not required) that you complete the earlier courses in this program. It’s helpful to be familiar with the following concepts: - installation of software on a computer platform - basic computer network terminology and concepts - common system administrator tasks and responsibilities This course has been designed to be completed completely in-browser. You don’t have to install any software on your computer. However, supplemental readings and instructions are provided, where appropriate, if you want to install the software and tools that we discuss in order to experiment on your own systems. Except as otherwise noted, the contents on this site are licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

From the lesson

Version Control and Testing

In the fourth week of this course, we'll learn about version control systems (VCS) and system testing. We'll explore why VCS are helpful for maintaining source code across programs and scripts. We'll learn how to use a popular type of VCS called Git and why remote repositories can help people develop a project collaboratively. By the end of this module, you'll understand the basic Git workflow, how to commit and "rollback" code, and even learn some advanced Git features (if you're interested). Using a VCS like Git is an awesome skill to have as an IT Support Specialist and will help set you apart from the crowd.

What is Git?2:09

What is GitHub?2:20

What does Git do?5:09

Anatomy of Commit Message3:13

The Basic Git Workflow5:23

The Git and GitHub Workflow3:40

Meet the Instructors

Google

Now, we'll focus on working with a local Git repository.

We'll dive into remote repositories and cloning a little bit later on.

Before you can use Git, you have to install it.

The directions found in the Git documentation are thorough and

really helpful.

Check them out for the best way to get Git into your platform of choice.

We'll be using Ubuntu in our examples.

That way, we can use a packaged management system, like Apt, to download and

install the software.

Once it's installed,

we should be able to verify the version we've got with this command.

First, all of the files you want to manage with Git have to be part of

a Git repository.

Remember they Git directory we learned about in the last video?

Well, you can load a Git repository in any file system directory

with the git init command.

So for example, this set of commands will create a normal file system

directory called scripts on a Unix like system,

then initialize an empty Git repository inside of it.

Your shiny new Git repository can now be used to record

the changes to files inside of it, very cool.

Let's check it out by changing into the newly created script directory and

having a look at the git config.

This config can be examined with the git config command.

There's a lot of info in there, some of which we'll cover later, but

pay special attention to user.e-mail and user.name lines.

This information will appear in your public commit logs if you use a shared

repository, and you might want to change them for privacy reasons.

You can check out setting your e-mail in Git and

keeping your email address private on the GitHub help site for how to do this.

If you add a new file in the directory,

like the scripts directory we just mentioned, it starts off as untracked.

You can make all kinds of changes to the file, but

until you tell Git to track it, Git won't do anything with an untracked file.

You could do this with the git add command from inside the repository.

The git add command will send a new file from untracked to the staged status and

change a modified file to staged.

Remember that when a file is staged, it's been added to the staging area and

is ready to be committed to the git repository.

Anything that's unstaged at this point, like stuff that you haven't run git

add on, will not be committed to the repository.

To initiate a commit of staged files, you issue the git commit command.

This will launch a text editor,

which is set in most operating systems by an environment variable like $EDITOR.

This is where you can write your commit message.

Voila, you've just recorded a snapshot of the code in your project.

It's stored in the Git directory we spoke about in the last video.

Remember that every time you commit you take another snapshot,

annotated with a commit message that you can review later on.

It's good to call out that at any point in the workflow,

you can check the status of what's tracked or staged using the Git status command.

For example,

To check the history of commits for your project, you can just the git log command.

Since we've done two commits, so far,

we get two entries in the log when we look at it.

Check out what Git tracks as part of the log.

The first line has the word, commit.

If we add the --decorate flag, we can get even more information.

Do you see the (HEAD -> master) portion?

This line gives us information about the commit itself.

The long string is the ID of the commit.

And the (HEAD -> master) portion,

shows which branch HEAD is pointing after the commit was made.

We'll dive deeper into this later.

Next, you'll see the person who made the commit is named the Author.

That's followed by the date and time the commit was made.

Finally, the commit message is displayed.

Remember that even though these commit messages are fine for

providing examples, in a real commit, you'd want to follow

the guidelines we outlined when we dove into the anatomy of a commit message.

Remember, you can always go back and

re-watch these videos to review the materials at any time.

You should check them out if you're having any commit issues.