Learning Objectives:

Utilize the code review workflow
Create, update, and execute pull requests on GitHub
Explain what a code review is
Use code reviews in GitHub
Explain the importance of managing projects and accepting or rejecting changes
Utilize issue trackers
Describe the methodology behind continuous integration

Table of Contents:

Pull Requests

Intro to Module 4: Collaboration

Over the past modules:

We've learned a whole about how to interact with Git.
We've covered how to use it both locally and remotely.
We've seen how to rollback bad changes, solve conflicts when collaborating with others, and a bunch of other little nifty things.

In this module:

We'll keep exploring the collaboration tools available in Git.
We'll learn about tools that allow us to send changes to projects that we aren't a member of, help us improve the quality of our code, and let us track our work better.

Some of these tools will be specific to GitHub, but most of the Git repository hosting services have similar tools.

In recent years, GitHub has become a super popular platform for collaboration across many projects. It's used heavily for open-source projects.

These are projects that allow anyone to use, copy, and modify their code.
Having the code published online means that anybody in the world can learn from what the project is doing, and even collaborate on fixes and extra features.

A Simple Pull Request on GitHub

As we called out, we can use GitHub to look at other people's code and collaborate with them. Let's see this in action by having to look at one of the projects from our colleague, blue-kale.

Okay, so our colleague has created the project to include all validation functions. Let's have a look at the validations.py file.

We can improve our colleague's code by fixing a typo. We'll click on the little pencil icon which let's us edit the file directly from the web interface.

We're trying to edit a file in a project that we don't have a right access to.

GitHub tells us it created a fork of this project for us, which we can commit our changes to.
And if we submit changes to this file, it will create a new branch so that we can send a pull request.

But what exactly is a fork?

Forking is a way of creating a copy of the given repository so that it belongs to our user. In other words, our user will be able to push changes to the forked copy, even when we can't push changes to the other repo.

When collaborating on projects hosted on GitHub, the typical workflows:

First, create a fork of the repo, and then work on that local fork.
A forked repo is just like a normal repo, except Github knows which repo it forked from.
So we can eventually merge our changes back into the main repo by creating a pull request.

A pull request is a commit or series of commits that you send to the owner of the repository so that they incorporate it into their tree.

This is a typical way of working on GitHub, because in most projects, only a few people have commit rights to the repo. But anybody can suggest patches, bug fixes or even new features by sending pull requests that people with commit access can then apply.

Typically, the owners of the repo will review the changes before merging them. Checking that they match the development guidelines for the project and that the license is valid and so on.

Let's fix the typo in the file to see what the pull request looks like. Once we're done making changes to the file, we can make a change proposal, by scrolling down and filling in the description of the change.

Clicking on the Propose file change button, we'll create a commit in our forked repo, so that we can send the change to our colleague.

But we haven't yet created the pull request that will send the changes to the owner of the original repo. On this screen, we can see a lot of information about our change:

We can see what repositories and branches are involved in the creation of the pull request.
We can also see that GitHub automatically created a branch called patch-1 for us.
And that our change can automatically be merged, no conflicts.
This window also lets us review the change before we create an actual pull request.

Once we're ready, we just click the Create pull request button.

This opens a text box where we can enter comments about our change.

In this case, a change is really simple, we just fixed the typo so there's nothing extra to add.

The checkbox at the bottom lets us allow edits from maintainers. This can be useful for example, if by the time a project maintainer gets around the merging or change, there's been more commits and our change needs rebasing. By allowing edits, the maintainer can do it themselves instead of asking us to do it.

We've created a pull request with our change. Our colleague can now look at it and decide whether they want to merge it to the project or not.

We checked out the simplest way of making pull requests, which is doing them directly through the GitHub interface. By using this workflow, you can already start contributing to projects on GitHub.

The Typical Pull Request Workflow on GitHub

We saw how to create pull request directly on GitHub by using the web interface to edit files.

This works for simple changes like fixing typos or adding documentation to a function, but it's not so great for making larger changes that we want to preview or test.

To do that, we'll normally have a local copy of the repo in our computer and work with the forked repo as a remote.

We'd need to use all the Git commands that we've learned up till now to do this. Let's check out this process by creating a fork of another repo.

On top of the validations repo, our colleague blue-kale has created a rearrange repo, and we want to help them out.

We'll go to the rearranged repo and create a fork by pressing the Fork button.

The copy will contain the current state of the repo including files and commit history. Once the fork is created, we're shown a page that corresponds to the same repo name, but it's under our user. It shows that it's a forked repo by stating the original repo under the name.

We can now get a local copy of the repo on our computer by copying the URL and then calling the git clone command with it.

We now have a new directory called rearrange with the contents of the repo.

We can look at the contents by changing into that directory enlisting all files.

We can look at the commit history using git log.

Now that we have a local copy of the repo, we can make any changes we'd like to it. For example, this project doesn't currently have a README.md file.

To do that:

We'll create a new branch called add-readme. We do it by running git checkout -b add-readme.

We can now edit the README.md file. The .md extension indicates that we're using markdown, which is a lightweight markup language. We can use it to write plain text files that are then formatted following some simple rules.

We save it and commit it.
Now, to push the change to our forked repo, we need to create the corresponding remote branch.We use git push - u origin add-readme.

when we push the change to the new branch, we got a message that we can create a pull request if we want to. First, let's check out how our file looks when rendered. Our README file rendered successfully.

We're ready to create a pull request for our change. To do that, let's look at the top of the Project page. GitHub tells us that our branch is ahead of the original repositories master branch by one commit, which is the commit we just made.

We can start our pull requests by clicking on the Pull Request link. As we called out, before creating a pull request, it's always important to check that the code will merge successfully. GitHub tells us that our change can be automatically merged, which is great news.

If this wasn't the case, we'd need to rebase our change against the current branch of the original repo so that it could be merged.

The window is showing us the TextBox where we can enter comments about our change. As we mentioned before, we should use this to explain why we're creating this pull request. This lets the person that will approve the change understand why they should merge the change into the main tree.
- Are we fixing a bug?
- This is a new feature to let the project support more use cases.
- How will the project benefit from including our change?
We can also use this box to explain how the change was tested.
- If the project includes automatic test infrastructure, our pull request should include a tests for our changes and we can state that all test still pass.
- But if there's no automatic testing, then we can use this box to explain how we tested the change manually.
We should also check that the change we're sending looks correct. It's always a good idea to double-check that we're sending the right change. To do that, let's look at the diff that appears at the bottom of the page.

We're ready. Let's click the Create Pull Request button.
The number next to the name of our pull request is the identifier that's used in GitHub to track issues and pull requests. We can use this identifying number to access this pull request anytime we need it.

But why would we need to access a pull request after we send it?

It's pretty common for project maintainers to come back with questions, comments, or even ask us to fix our pull requests.

Imagine you've just finished preparing a pull request for a great new feature, and you get a comment saying that it's missing some documentation.

What would you do?

Updating an Existing Pull Request

When we send a pull request, it's pretty common to receive some comments from the project maintainers asking for some improvements.

The improvement could be to add documentation or tests, or maybe we need to make sure that change works for all cases or that it follows the project style guidelines.

There's nothing wrong with getting these comments, it actually shows the project maintainers are interested in our change.

To get our change approved, it's important that you address the comments.

We got a comment saying that our README was too short and they'd like us to add an example.

To address this comment, will add more details to our file. We'll start by explaining that the function rearranges LastName, FirstName into FirstName LastName and then we'll add an example.

Now we can add our changes and commit them to the repo as usual.

Now that we've pushed our change back to the repo, let's check our pull request in GitHub.

In the Commit's tab, we can see our two commits.

Our commit now shows up as a part of the same pull request.

It's important to notice here that we just pushed our commit to the same branch as before and GitHub automatically added it to the pull request.

If we wanted to create a separate pull request, we would need to create a new branch instead.

If we go to the Files Change tab, we can see all files affected by the pull request, no matter which commit they were changed in.

Whenever we look at the diff generated by a commit or a chain of commits, GitHub will show a color diff for the changes that we've made.

It will use green for new lines and red for lines that were deleted.
If only a part of the line changed, it will highlight that specific part of the line.

In this case, it's a new file, so all the lines are additions.

Check out how we see only one file even when there are two separate commits.

What we're seeing is the difference between our repo and the original repo we created the pull request for.

You can also click on the preview icon and show the rendered markdown contents. Github renders our file and highlights the changes.

Keep in mind that each project in GitHub may work slightly differently.

Some projects may ask you to have only one commit in your pull requests,
other projects may ask you to rebase against the latest master branch when your pull request is ready to be merged back into the main tree.
Github allows projects to set their contribution guidelines. You'll find a link to them whenever you create a new pull request or issue in a project. So make sure you've read these guidelines and that your pull requests match them.

In this section, we saw how to update our pull requests by doing new commits in our local Git repository and pushing them to the remote repository.

We'd seen before how to use the Git web interface to create new pull requests and we can use this interface to update a pull request.

This can be handy when the change that we want to make is small like fixing a typo or adding an extra sentence to the documentation.

Squashing Changes

As we've caught up before, you shouldn't rewrite history when the commits have been published. That's because someone else may have already synchronized that repo with those contents.

This rule is waived with pull requests, since it's usually only you who have cloned your fork of the repository.

So say the project maintainers ask us to create a single commit that includes both changes and a more detailed description than the one we submitted.

We can do that by using the interactive version of the rebase command called rebase -i, as the parameter to the command will pass the master branch. So we'll call git rebase-i master.

When we call an interactive rebase, a text editor opens with a list of all the selected commits from the oldest to the most recent.

By changing the first word of each line, we can select what we want to do with the commits.

The default action here is pick which takes the commits and rebases them against the branch we selected.

This is what we do with git rebase in an earlier video when we called it without the dash i flag.

But now we can change the action to something else.

The comments in the file tells all the different commands we can use for our commits.

For example:

We can reword a commit message keeping the changes as they are but modifying the commit message.
We can also edit the commit to add or remove changes from it.
We have two options for combining commits, squash and fix up. In both cases, the contents of the selected commit are merged into the previous commit in the list. The difference is what happens with the commit messages.
- When we choose squash, the commit messages are added together and an editor opens up to let us make any necessary changes.
- When we choose fix up, the commit message for that commit is discarded.

For our example, we want to use squash so that we can combine both commits but also modify the commit description.

So let's change the pick command in the second line to squash it into the first one, then we'll save and exit the editor as usual.

Once we've told git that we want to squash a commit unto the one before it, we're given another file to edit. In this case, it's the combined commit message.

We want to improve the description by adding more info about our change.

Our rebase worked. Let's check the output of git show to see the latest commit and the changes in it.

We got exactly what we wanted here, our two changes have been combined into one that contains the whole new file and the right commit message.

Before we try to push this change to our repo, let's call git status to check the info that git gives us about the current state.

Git tells us that our local branch has one commit, which is the rebase we just did.

It also tells us that the origin/add-readme branch has two commits. These are the two commits we had already pushed to the repo.

Let's look at the graph history of our commits by calling git log --graph --online --all for all branches, and -4 for just the latest four commits.

We can see that the two commits pushed to the origin/add-readme branch show up in a different path than the commit that's currently in our local add-readme branch.

This is expected whenever we do a rebase because the old commits are in the remote repo and we have a different commit in our local repo.

As we expected, git doesn't like us trying to push our change because it can't be fast-forwarded. But in this case, we don't want to create a merge.

Instead, we want to replace the old commits with the new one. To do this, we will call git push -f to force git to push the current snapshot into the repo as is.

This time, our push completed successfully. Git tells us here that we forced an update.

Let's look once again our history graph by running git log -- graph --one line --all -4.

This time, it's just one commit on top of master. The divergence is gone. Now let's look at the contents of the pull request. We've managed to combine both are commits into one by using the interactive version of git rebase.

You now know how to create a pull request on GitHub, how to update a pull request, and squash changes.

Git Fork and Pull Request Cheat Sheet

Check out the following link for more information:

https://help.github.com/en/articles/about-pull-request-merges

Code Reviews

What are code reviews?

GitHub and other repository hosting services offer tools for doing code reviews on their platform.

And while this is called code reviews, we can actually use the same tool and process to do reviews of any text file including configuration and documentation.

Doing a code review means going through someone else's code, documentation or configuration and checking that it all makes sense and follows the expected patterns.

The goal of a code review is:

to improve the project by making sure that changes are high quality.
It also helps us make sure that the contents are easy to understand.
That the style is consistent with the overall project.
And that we don't forget any important cases.

Reviews increased the number of eyes that have checked the code.

This increases the code quality and reduces the amount of bugs.

It doesn't mean that there'll be no bugs, but at least the most obvious bugs will be caught.

Also, this helps spread knowledge since both the code writers and the code reviewers now know what the code is doing.

When we work in the same office as our teammates, we can do reviews in person by looking together at the changes and discussing how the contents fit together.

But when the person that we're working with is in a different office or time zone We're better off using a Coder V tool. Coder V tools let us comment on someone else's code. These let us leave feedback on how they could make their code better.

Common code issues are:

unclear names that makes the code hard to understand.
Forgetting to add a test, or
forgetting to handle a specific condition.

If we're writing documentation, our reviewer can help us catch typos and things that aren't totally clear.

On platforms like Github, it's common for projects to only requires reviews for people that don't have commit access while the project maintainers can commit directly.

Today, some open source projects and lots of companies require code reviews for everybody. This isn't because they don't trust them, but because they want the highest quality code. And code reviews are how they get there.

One thing to always remember, code reviews are not about us being good or bad coders, they're about making our code better.

Like everybody else after toiling for hours on a problem and finally solving it, all I want to do is submit my code and be done with it.

But this rarely happens. Code reviews usually send me back to the drawing board with small errors and nitpicks, but that's a good thing.

These code reviews point out things that we might have missed along the way and ensure that our code makes sense to others.

The Code Review Workflow

Now, we'll check out a typical code review using a reviewing tool. Imagine we've just finished a bunch of code changes, now, we'll ask a reviewer to look at our code.

The reviewer might say that everything is okay and our changes approved, but usually they'll find something that needs improving. So they'll add comments to our changes explaining what needs to be fixed and how.

When we get the review comments will address them by fixing our typos, adding any missing tests and so on. After addressing a comment, we can mark it as resolved so that we know it's been taken care of. If there's something that we aren't sure how to do or we think a different approach might be better, we can reply to the comment and ask our reviewer for more information without marking the comment as resolved.

Once all comments have been resolved and our viewer is satisfied with the results, they'll approve the change and we'll be able to merge it.

There's a wide range of things your reviewer might have to say about your code.
Sometimes, you might have forgotten to take into account something important and you'll need to do significant work to fix it.
Sometimes, your reviewer might point out something small, that's not really critical.
And the comment is mostly a suggestion for making the code better. These comments are usually prefixed, saying that it's a Nit.

Whatever it is, it's important that you take the time to understand what the comment is and what you need to do to address it.

For example, if you've written a piece of code and your reviewer asks you to explain why or how the code is doing something, it might be tempting to just answer their question in the comment and mark it as resolved. But this isn't a great idea, because only the reviewer gets to see your answer.
- Instead, it's better to take this as an opportunity to make the code clearer. For example, you could do this by using better variable names or splitting a large piece of code into smaller functions.
- On top of that, you can add comments to the code and documentation to your functions to make sure that the how and why are clearly explained.
It's common for code reviews to include several comments about the style of the code.
- To avoid a lot of back and forth, it's a good idea to refer to a style guide that explains the preferred coding style for the project.
- For example, lots of Python projects, use the PEP8 style guide. If the project you're contributing to doesn't include a style guide, make sure that you ask for one.

In some code reviewing tools, you'll need one of the project maintainers to approve your code before it's submitted.

In other tools, you'll just need to get a couple +1s from contributors to the project before you can submit.

The goal is to always ensure that your code has been reviewed by people who are familiar with the project, so that it's ready to be submitted.

How to Use Code Reviews in GitHub

Now, let's check out how the process of doing code reviews looks on GitHub.

Remember, a while back in this module, we created a pull request that added a read me file. Conveniently, our colleague just replied with a few comments.

We can view all changes requested for the file we created by clicking on the view changes button.

Our reviewer made three comments about our file.

Let's fix these. Since we want this change to be a part of the previous commit, we'll call Git commit -a with the --amend flag, which will edit the original commit.

Once we've done that, let's call Git status to see what Git has to say about our repo. Just like before, we see that our change has diverged from the origin/master branch.

You might remember that git commit --amend modifies commits. So it's not safe to do with commits that have been pushed to the repo. Using amend is pretty much the same as creating a new commit, and then using an interactive rebase to fix up a change. So, the commit gets replaced by a completely new commit with a completely different commit ID.

This means that to push it, we'll need to use the -f flag again.

Remember that forcing pushes is fine for pull request branches because nobody else should have cloned it. But this isn't something that we want to do with public repos.

We've done what our colleague asked. Let's now go back to look at the pull request and resolve the comments. See that comment that says outdated, that's because we've pushed a new version since we've made the change.

But, since we've taken care of their request, we can ignore the outdated comment and just resolve the conversation.

We've addressed all the comments.

We can leave a message in our conversation to let our reviewer know that we've resolved all the comments and ask them to take another look.

Our reviewer can now check out the new changes and approve them if they're satisfied.

More Information on Code Reviews

Check out the following links for more information:

Managing Projects

Managing Collaboration

We've looked at how we can collaborate with others using tools provided by platforms like GitHub. These tools can be very helpful but some coordination outside of the platform is always going to be needed.

For example, the project you're working on might need up medium or large refactor that will affect multiple lines of code across several files.

It's important to give your colleagues the heads up that this refactor is coming.

If possible, try to do the refactor while the other developers are working on a different part of the project because this helps avoid large and complicated conflicts.

We've called on a bunch of times that documenting your work is super important. When working together with a large group of people, documenting what you do and why you do it becomes even more important otherwise you'll spend most of your time answering everybody else questions.

Also, say there's a problem with your service while you're on vacation or the person who developed the code ison the other side of the world and currently sleeping. In these situations, the documentation needs to be good enough to help someone else fix the problem.

The most basic form of this is writing clear code with good comments and documentation for those functions in the code.

On top of that, you'll want to create documentation files to let others know how they can interact with your project like the Changelog file that we created an earlier video.

If you're a project maintainer, it's important that you are reply promptly to pull requests and don't let them stagnate.

The more time that passes until a pull request gets reviewed, the more likely it is that there's a new commit that causes a conflict when you try to merge in the change.

On top of this, if the person contributing the changes of volunteer that's just trying to help, they may lose their motivation to work on the project if you make them wait too long for feedback.

Another thing to remember when you maintain a project especially if it's an open source project that volunteers are contributing to is that it's important that you understand any changes you accept.

You never know if the other person is going to stick around to maintain the code after you merge it in so you better make sure you can do that.

You should also be careful with which patches you accept or reject.

Accepting everything that gets sent your way might make your project grow too much and become unmanageable or it might take into account too many corner cases and cause complicated code that's hard to maintain.

On the flip side, if you don't accept any pull requests you'll discourage contributors and miss out on keeping your project active and relevant.

If you're contributing to a project, you want to check out the style guide and make sure you follow it. If you own a project, it makes sense to create a style guide so that others know what you're expecting from them.

When it comes to coordinating who does what and when, a common strategy for active software projects is to use an issue tracker.

On top of that, when the project is large enough, it's important to have another way of communicating and coordinating between contributors.

For many years, most projects used mailing list and IRC channels for communication. Recently, new forms of communicating have gained popularity like Slack channels or Telegram groups.

If you're managing your own project, choose whatever communication medium best fits your needs and those of your contributors.

If you're collaborating with a project you don't own, you'll want to find out what channels are being used for collaboration and with that you now have a rough idea of how to collaborate with others across the internet.

Up next, we'll talk about two important tools that can help us collaborate better, tracking issues and continuous integration.

Tracking Issues

Deciding who's going to do what is critical when collaborating with others.

Imagine that you and your colleagues decided that you'd work on building automation software, for keeping the computers on your network up to date.

But then instead of dividing the task into smaller pieces and assigning them to different people, you just randomly started working on some part of the infrastructure. The result would probably be total chaos, with different pieces of software that won't work well together, and lots of gaps that nobody worked on.

For small teams, it's usually easy enough to discuss in person who's going to be working on what. But as soon as the group starts growing, talking about responsibilities and what to do next becomes more of a hassle.

That's when a tool like an issue tracker or bug tracker can help us coordinate our work better.

An issue tracker tells us the tasks that need to be done, the state they're in and who's working on them.
The system also let's us add comments to the issue, these comments can be super helpful. They can give us more details about the problem, explain a way to solve it, or detail how to test if it's been solved.
Issue trackers aren't just useful for people actively working on projects. They also let users report bugs when they come across them, even if they don't know how to solve the problem. Sometimes users come across problems that we never even thought possible. And having them report these issues through a bug tracker can help make our projects better.
And the tracker can also help volunteers that want to start contributing to the project. Having a clear visible list of the pending work, lets new contributors figure out how to help and where to jump in.

There are a bunch of different solutions to track bugs or issues.

There's a popular bug tracker called Bugzilla, which is used by quite a few open source projects.

On the flip side, platforms like GitHub have an issue tracker baked in. So, if you're hosting your project there, it can be very handy to track work on your project. Like the problems to solve, the features to add and the use cases to include it.

This is the list of issues for our health-checks projects. For now, it only has one issue asking us to update our documentation.

One of our colleagues suggested that we create a new health check that verifies if there are any critical error messages inside the system logs like current log or syslog. Errors that appear there might help troubleshoot some interesting problems. So, this sounds like a good idea for a new check.

Let's create an issue for this feature by clicking on the New issue button. For the title of the issue, we'll say that we want to check for critical errors in system logs. And for the issues description we'll say that the new check should go through var/log/currentlog and var/log/syslog and check if there are any critical errors that need attention.

When writing in issues description, it's a good idea to include all the information that we have about the problem or missing feature and any ideas on how to solve it.

And if new information comes up later on, it can be added as additional comments on the same issue.

Great, we're now ready to submit the new issue.

The issues in the list all have numbers that identify them, as we called out in an earlier video, in GitHub, each issue or pull request in a project has a unique number associated with it. So, if we have a pull request with the ID five, there won't be an issue with ID five.

GitHub will automatically reference issues and pull requests and comments when we mention them using the hash tag number format. For example, if we use #2 in a comment, it will automatically reference the issue we just created.

If you're fixing an issue through a pull request, it's possible to automatically close the issue directly once the code is merged. To do this, you need to include a string like closes:#4 in your commit message or as a part of the description of your pull request.

Once the code gets merged into the main tree, GitHub will automatically close the issue with a message linking it to the new commit.

Let's try this out by updating the documentation, like the #1 issue requested.

This issue seems easy enough to fix, we need to update the README file to use the new file name and explain a bit more about how our script works.

Before we start working on this, let's get the issue assigned to us. Assigning issues to collaborators helps us track who is working on what. By assigning the bug to yourself, you can let others know that you're working on it, so they don't need to.

We've updated the documentation, let's save the file and commit this change.

Now let's go back to the issue that we were addressing. We see that our issue is automatically closed with the commit we pushed. We can click on the commit ID to see the full commit.

So here's the commit message we created with the associated change. See how the #1 that we included as a part of the commit message is automatically detected as a link to the #1 issue.

Continuous Integration

We can write automated tests to test the code for us and then use a continuous integration (CI) system to run those tests automatically.

A continuous integration system will build and test our code every time there's a change.

This means that it will run whenever there's a new commit in the main branch of our code.
It will also run for any changes that come in through pull request. In other words, if we have continuous integration configured for our project, we can automatically run our tests using the code in a pull request. This way, we can verify that the test will pass after the new changes get merged back into the tree and that means instead of hoping our collaborators will remember to properly test their code, we can rely on our automated testing system to do it for us.

Once we have our code automatically built and tested, the next automation step is continuous deployment which is sometimes called continuous delivery (CD).

Continuous deployment means the new code is deployed often.

The goal is to avoid roll outs with a lot of changes between two versions of a project and instead do incremental updates with only a few changes at a time. This allows errors to be caught and fixed early.

Typical configurations include deploying a new version whenever a commit is merged into the main tree or whenever a branch is tagged for release.

There's a large world of tools and platforms related to CI/CD which is what the whole system is usually called. One popular option is Jenkins which can be used to automate lots of different types of projects.

Some repository hosting services like GitLab provide their own infrastructure for doing continuous integration.

GitHub doesn't offer an integrated solution. Instead, the popular alternative is to use Travis which communicates with GitHub and can access the information from GitHub projects to know which integrations to run.

No matter which tool you use, there are a bunch of concepts that you'll need to deal with when creating your own CI/CD:

The first one is a concept of pipelines. Pipelines specify the steps that need to run to get the result you want. For a simple Python Project, the pipeline could be to just run the automated tests. For a web service written in Go, the pipeline could be compiled the program, run the unit tests and integration tests and finally deploy the code to a test instance.
Another concept that turns up when doing CI/CD is artifacts. This is the name used to describe any files that are generated as part of the pipeline. This typically includes the compiled versions of the code but can include other generated files like PDFs for the documentation or OS specific packages for easy installation.
On top of this, you might want to keep the logs of the pipelines build and test stages to review if things fail.

When setting up CI/CD, we have to be careful about how we manage secrets.

If our pipeline includes deploying a new version of the software to a test server, we need to somehow give the software that's running the pipeline access to our test server.

There are a bunch of different strategies to do this, like exchanging SSH keys or using application specific API tokens.

For some pipelines, it might be unavoidable to use one of these methods but be aware that you're giving access to your test servers to the owner of the service that's running the pipeline for you. It's a bit like giving your house keys to the person checking your heating once a year.

So two things to remember:

first, make sure the authorized entities for the test servers are not the same entities authorized to deploy on the production servers. That way, if there's any kind of compromise in the pipeline, your production server is not affected.
Second, always have a plan to recover your access in case your pipeline gets compromised.

If you want to set up Travis for your GitHub project, you can do that by logging into the Travis website at http://www.travis-ci.com using your GitHub account then enable the projects that you want to continuously integrate.

After that, you'll need to add a configuration file to your project written in YAML format that states the language your project is in, in which steps to take for the pipeline.

This file can be very simple if your project files are typical configuration for the language you're using but can also become very complex if you want to run a complicated pipeline with lots of stages and steps outside the defaults.

Additional Tools

Check out the following links for more information:

Module 4 Review

Lab remark:

Module 4 Wrap Up: Collaboration

We've checked out a lot of tools for better collaboration through GitHub.
We looked at the typical workflow for pull requests, how to update and squash changes.
We learned how code reviews make our code better by helping us catch bugs, typos and other problems.
Finally, we looked into some advanced tools for collaboration, like issue trackers or continuous integration services.

All these builds on the other tools and techniques for version control that we've covered through out the course, like checking the change history, rolling back a bad change, and merging other people's changes.

Course Wrap Up

Congratulations!

By now, you're practically an expert in using Git to control your code.

You've learned how to:

track your changes,
revert changes when they don't make sense,
resolve conflicts if you happen to edit the same code as your collaborators,
and a bunch of other techniques for effectively collaborating with others.

Sneak Peek of the Next Course

During this course we've learned a lot about version control. We discovered how we can use it to understand the history of our projects. And to roll back to earlier versions if an update causes problems.

In our next course, you'll learn a lot more about finding the root cause of problems and figure out how to fix them.

We're going to learn how to troubleshoot hard problems.
We'll learn how to find a reproduction case,
how to reduce the scope of a problem to make it easier to understand and debug.
What to do when our computers are running out of resources like memory or disk space.
And also how to deal with programs running slowly.

Sara's PHD

Week 4: Collaboration