Week 1: Software collaboration

Have you ever accidentally
deleted something on your device and wished you
could undo your mistake? Wouldn’t it be great if
you had a time machine to go back and
undo your mistake? While humans can’t yet
to travel back in time, programmers working on projects can do something quite like it. They do this using a system
called version control. As a programmer, you’ll be
working with many files in your project and
it’s important to keep track of the
changes being made. Version control is a
system that records all changes and modifications to files for tracking purposes, and is essential to your day-to-day
development activities. In this course, you will
become familiar with version control and how it
relates to development. By the end of your studies, you’ll understand what
version control is, how it works and how it is used. There are both centralized and distributed control systems available and you’ll examine the different types of
workflows available. Conflict resolution is an important aspect
of version control as it helps users manage file and version
conflict issues. You’ll get to explore popular
methods of version tracking using version control
technologies like Git and GitHub, and you will learn
how to create and clone a repository in GitHub. In addition, you
will become familiar with Git concepts such as add, commit, push and pull, branching and forking,
diff and blame. As well as focusing
on version control, the course also
explores the use of command-line syntax with an
emphasis on Unix commands. There are many videos
in your course that will gradually guide
you toward that goal. Watch, pause, rewind, and re-watch the videos until you are confident
in your skills. Then you’ll be able to consolidate your
knowledge by consulting the course readings
and put your skills into practice during
the course exercises. Along the way, you’ll
encounter several knowledge quizzes where you
can self-check your progress. You’re not alone in considering a career as a web developer, and the course
discussion prompts enable you to connect
with your classmates. It’s a great way to
share knowledge, discuss difficulties,
and make new friends. To help you be successful
in the course, it’s a great idea to commit to a regular and
discipline approach to your learning regime. You need to be as serious as you can about your study
and if possible, map out a study
schedule with dates and times that you can devote
to attending the course. Of course, this is an online self-paced program
and you can study a dates, times, and places that
suit your lifestyle. However, it might
help to think of your study in terms of
regular attendance, just as you might have to do at a physical
learning institute. You may have encountered new technical words and
terminology in this video. Don’t worry if you don’t fully understand all these
terms right now, everything you need will be
covered during your learning. In summary, this course
provides you with a complete introduction
to version control and it is part of a program
of courses that lead you towards a career in
software development.

Communication is the most important skill for
collaborating with other developers to
ensure that you’re on the same page when you’re
building products. Also so that people are keeping track of
each other’s timelines, and the understanding of what the product requirements
are consistent. Hi, I’m Laila Rizvi. I am a back-end software
engineer at Instagram, working on Instagram
calling in San Francisco. Effective collaboration
is important so that we can move cohesively together on large projects with people that have a
wide range of skills. As engineers actually have to collaborate with
one another a lot. When we build features together, we have to work in
parallel with one another to design the best
features for our users. We also have to collaborate with a lot of non-engineers a lot. For example, when we
built Instagram Live, we had to work with
our product managers to figure out what
we should build. We had to work with
our user researchers to figure out what
areas we should focus on to build the best
products for our users. We had to work with our
designers to figure out the right look and
feel for our product. We had to work as
engineers to figure out what we can actually build
in the timeline that we had. Communication, is one of the most important skills for working with other developers. Learning how to give developers the right amount of context
for what they’re working on. Learning how to
ruthlessly prioritize your work is also very important
as a software engineer, there’s always going to
be an endless amount of things that you can do
to improve your product. Learning which things are
most important to unblock other developers or unblock yourself is the most
important skill. The last thing that’s really
important to learn as a software developer is to accurately estimate
your products, when you first start out, it’ll be a little bit tricky, but over time learning how to say how long the
project is going to take and being able to explain the trade-offs is going
to be very critical. The skills you need as
a software developer changes from company to
company a little bit. When you’re at a big
company like Meta, engineers are much
more specialized. Whereas if you’re in a startup, you wear many different hats. As an engineer at Meta, we have to learn to be able to give just the right
amount of context to people for what
we need to get done. Because we’re
working with people a little context on
the work we’re doing. There’s so many engineers there. But if you’re in a startup, if people generally
have a little more context on what
you’re working on, but they might not be as
specialized in that area, you have to do a little bit
more learning potentially, and you have to maybe give
less context to them. Some challenges I’ve
encountered while learning to collaborate is that, I have to learn how to adjust, how I work with different people depending on their
work preferences. Some people I work with
are visual learners. I learn to whiteboard
when I’m talking to them. Some people I work with, like to think before they speak. I learned to be a little
more patient when I’m talking to them,
to listen to them. A scale that I’m working
on learning to develop my own career is I’m learning
how to work on mobile. I’m a back-end engineer, and I work with mobile engineers every single day to better
build products for them. It’s nicer for me to
understand how they operate, how their codebase work so that we can build better
things together. To learn mobile, I took an
Android boot camp class at Meta that Meta provided for back-end engineers interested
in learning mobile. After I finished the course, the Android engineers on my team have been giving
me small tasks and small projects for
me to drive so that I can learn a little bit
more about how they work. Practicing effective version
control leads to better collaborating
because it helps you understand why certain
changes were made. If you look at commit. It also helps you
context switch between different features or projects
that you’re working on. Effective collaboration led to a better outcome on a
recent project of mine. I’m a back-end engineer, and I was driving
the back-end parts of IQ project for my team, I had unexpectedly take
time off but I had a lot of clear commits for
my code changes in Git. I had a lot of documentation
for my team so they were able to easily pick
up where I left off, and the project ended
up staying on track. You should keep learning to collaborate with other people, because the more
people you work with, the better products you build, because you’ll get
different perspectives on what you’re building. It’s rewarding because
your product that you’re working on ends up being better, the more people you work with, the more people you
can learn from. Ultimately it’s rewarding, because the product that you
build is going to be better. Because it’s going
to have a lot more different input and a lot more different perspectives
for how it should be built.

Version Control for Developers: Mastering the Time Machine

Ever stared at buggy code and wished you could hop back to a clean, working version? Fear not, developers! Version control is your time machine, a system that tracks every change to your code, letting you rewind, collaborate, and ship awesome software confidently. Buckle up, let’s explore this essential developer tool!

What is Version Control?

Imagine a magical document that remembers every edit, deletion, and revision. That’s essentially what version control systems (VCS) do for your code. They meticulously track every change, creating snapshots of your project at different points in time. Need to undo that accidental deletion? Version control has your back.

Types of Version Control:

• Centralized VCS: Think of a central server storing all code versions. Developers “check out” a copy, work on it, and “check it in” back to the server, keeping everyone in sync. Examples: Subversion, CVS.
• Distributed VCS: Like having individual time machines! Each developer has a complete copy of the codebase, making offline work and collaboration easier. Examples: Git, Mercurial.

Key Features of Version Control:

• Revision History: Explore a timeline of changes, understanding how your code evolved.
• Branching and Merging: Create separate “branches” to experiment without affecting the main code, then seamlessly merge them back in.
• Collaboration: Work on the same code with teammates, tracking conflicts and ensuring everyone’s on the same page.
• Rollbacks: Accidentally messed up? No worries! Revert to any previous version with ease.
• Efficiency: Automate tasks like backups and versioning, freeing up your time for coding magic.

Benefits for Developers:

• Confidence: Ship code with confidence knowing you can always retrace your steps.
• Collaboration: Work seamlessly with teammates, avoiding code conflicts and confusion.
• Experimentation: Fearlessly try new things without jeopardizing the main codebase.
• Efficiency: Work smarter, not harder, with automated tasks and versioning.
• Documentation: The revision history serves as a living document of your code’s evolution.

Getting Started with Version Control:

1. Choose a VCS: Git is the most popular choice for its flexibility and power.
2. Install and configure your VCS: Follow the documentation for your chosen system.
3. Learn the basics: Commands like add, commit, push, and pull are essential.
4. Practice, practice, practice! Start with small projects to get comfortable with the workflow.

Additional Resources:

• Git documentation: https://git-scm.com/
• Interactive Git tutorial: https://github.blog/2012-07-04-try-git-in-your-browser/
• Online courses and tutorials abound!

Remember, version control is not just a tool, it’s a mindset. Embrace it, and watch your development workflow transform for the better. With this time machine in your toolbox, you’ll be coding with confidence, collaborating like a pro, and shipping software that rocks!

So, what are you waiting for? Go out there, conquer version control, and unleash your inner coding time traveler!

Your development team is tasked to develop an app. Your project manager leads you to work in an Agile way of working where tasks are planned and executed in a two-week cycle.  This is done to ensure which of the following benefits?

Efficiency

Well done! You, as a developer, will normally work on a project alongside many developers and team members with other skillsets. You and your team need to be efficient to make the project a success. To achieve this, you and your team normally work in an agile process.

Have you ever worked
on a document, made changes to it, and wished you could
have gone back to your first version
a few days later? Can you remember that feeling of wishing you could
travel back in time? For developers,
this time machine exists and it’s called
version control. In this video, you’ll learn
about version controls, primary features, and benefits. Version control is a
system that records all changes and modifications to files for tracking purposes. Developers also use the
term source control or source code management. The primary goal of any version control system
is to keep track of changes. It achieves this by
allowing developers access to the entire
change history with the ability to
revert or roll back to a previous state
or point in time. There are different
types of changes, such as adding new files, modifying or updating
files, and deleting files. The version control system is the source of truth
across all code, assets, and the team itself. Let me give you an example
that we’re all familiar with. In word processing applications, version control functionality
is available to provide users with the safety net of
auto-saving the document. The application creates
a restoration point on each auto-save to which the
user can revert if required. Version control systems for coding projects tend to
be a bit more complex, but their underlying
functionality follows the same process. Working as a developer, you need to become familiar
with many different tools, and version control
is one of them. For developers, especially
those working in a team, there are many benefits
associated with version control. These include; revision history, identity, collaboration,
automation, and efficiency. Let’s explore these
in some more detail. Revision history
provides a record of all changes in a project. It provides developers with
the ability to revert to a stable point in
time in cases where code edits cause issues or bugs. The ability to roll back to
a particular version or time allows teams to work faster and deliver code with
more confidence. Keeping a record of
changes is great, but it doesn’t have as much
value if you don’t know who is responsible for adding
or changing a record. All changes made are always recorded with the identity
of the user that made them. Combining this feature
with the revision history allows teams to see not only
when the changes occurred, but also who made the changes. Teams can also
analyze the editing, creation, and the deletion of files on the control system. As a software developer, you will often work with a
team to achieve a common goal. This can be adding
new features to an existing project or
creating a brand new service. In all cases, a
version control system allows the team to submit their code and keep track of any changes that
need to be made. Another important aspect of a version control system is something called a peer review. Developers working
on a task create a peer review once the code
is ready for inspection. The peer review aims to
get other developers on your team to review the code and provide feedback
where necessary. The ability to create
and deliver code on a wide scale is complex
and time-consuming. Version control helps keep
track of all changes. It plays an integral role in the explosion of
development operations, or DevOps, as it’s
commonly called. DevOps is a set of
practices, philosophies, and tools that increase an organization’s
ability to deliver applications or services to
a high quality and velocity. Version control is a key
tool in this process, and it is used not only to
track all changes but also to aid in software quality
release and deployments. You as a developer, will usually work on
a project alongside many developers and team
members with other skill sets. You and your team need to be efficient to make your
project a success. You and your team may work using processes from the
agile methodology. In an agile process, a team normally plan and execute two weeks of
work to complete, which is called an iteration. Each iteration has
a list of tasks to complete before
the two weeks ends. These tasks, while
complex in some cases, are aided by having
version control in place. If you would like to learn more about the agile methodology, there is a link to an
additional reading at the end of this lesson. Testing and having some
level of automation on every task introduced allows the team to be more efficient. It also ensures more confidence
that any new feature being introduced will not
break any existing flows. You now know what version control is all
about. Great work. Now that you have a
better understanding of the goals and benefits
of version control, you are ready to learn
how to start using it.

An interesting fact about
collaborating on projects that Meta is that engineers drive
every project at Meta. They’re in charge
of coordinating with product data scientists, researchers on what we’re building and the
timelines for that. Whereas another company’s
product managers or leadership is often in
charge of each project. I’m Laila Rizvi, I’m in back-end
software engineer on Instagram calling
in San Francisco. In this video, I
hope you learn that effective collaboration
is important for engineers’ success at
Meta and learning how to use version control at Meta
is also very important. As a back-end engineer
on Instagram calling, for my role I collaborate with
other mobile engineers and my department on a
daily basis so that we build the best
products together. I also collaborate with
Instagram messaging a lot because calling and
messaging are closely tied. I also work with
non-engineers like product and data scientists
regularly as well. To collaborate effectively
with my coworkers, we message each other on
chat to unblock one another, but when something
wants a meeting, we will schedule a meeting. Something wants a document, we collaborate
together on a document with comments and leave
notes for one another. Version control for Instagram
is interesting because we have one giant
monolithic repository for all of our
code for back-end. That means that whenever
I’m making a change, the code that I’m writing in is shared with every
other Instagram team. It is risky in some ways, but it’s also nice and others
so I can reuse their code. The other thing
that’s interesting about version control at Meta is that any engineer
can improve any change. At Meta, they’re big on this saying that nothing at Meta
is someone else’s problem, so that means that
any engineer can actually work on anytime
that they want to work on. Version control at Meta
is a little different than version control at
a lot of other places while Meta has a giant
monolithic repository for our code where we
continuously release our code. Many other companies have smaller repository called
micro-services for each team, so each team has
their own code-base and only they work in it. They use branches so that
they can take their code and merge it back with the master branch further team or product. This is great for smaller
teams in some ways, but it has its cons and that
you might run into a lot of merge conflicts at Meta because we have so
many engineers. They would be too many
merge conflicts if we add branches for each
team in the company. Some collaboration challenges
for version control on my team is that because we
use a monolithic repository, merge conflicts happen a lot. We try to write smaller changes so that we can
easily revert them. We also try to add a lot
of gatekeepers so that if we shift something to
production on Instagram, we can easily turn it off without waiting
for any rollback. We also share our code
with Messenger calling. We also have to
add a lot of tests so messenger doesn’t break us. Get blame is a way
for us to look at the revision history for files. It helps us so that
if I’m looking at a line of code and I
don’t understand it, I can figure out who wrote that code and reach out to them. I can also figure out what
they were trying to do. In that code, they write a message saying what
the change is for. It’s also great so
that I can figure out what chains to revert if I’m
trying to revert a change. I use it every single day when I need to understand
what some code is doing, I’ll reach out to the point of contact that wrote that code which is especially helpful at Meta where there’s
so many engineers, I often don’t know the person
I need to get a hold of, so seeing their code helps. In this video, I hope you
learn that learning how to work together effectively
and collaborating well, as well as learning how
to use version control effectively is critical
for success at Meta. Getting a diverse set of perspectives on what
features you should build, who you should build for, what a feature might need or
how it can improve is really helpful and the rewarding
part is that your end result, your project ends
up being better.

You are part of a development team and one of your colleagues ask you if a Centralized Version Control system (CVS) contains a server and a client. What would your answer be?

Yes

That’s correct! A Centralized Version Control system (CVS) contains a server and a client.

As a developer
working in a team, you are continually writing, changing, or updating
existing source code. It may happen that while you were working on a new feature, another developer in the team is busy fixing an unrelated bug. With multiple developers all working in the same code base, keeping track of all of those additional updates
can be problematic. Luckily, version control addresses these
kinds of problems. In this video, you will discover the different types of
version control systems, learn how they operate, and learn about their
similarities and differences. There are many different version control
systems available. For example,
Subversion, Perforce, AWS Code Commit, Mercurial, and Git
to name a few. Version control systems can be split into two types
or categories. Centralized version
control systems and distributed version
control systems. Both types are quite similar, but they also have
some key differences which set them apart
from each other. Let’s start with centralized
version control systems. Centralized version
control systems, or CVCS for short, contain a server and a client. The server contains the
main repository that houses the full history of
versions of the code base. Developers working
on projects using a centralized
system need to pull down the code from the server
to their local machine. This gives the user their own working copy
of the code base. The server holds the
full history of changes. The client has the latest code, but every operation
needs to have a connection to
the server itself. In a centralized
version control system, the server is the central
copy of the project. After making changes
to the code, the developer needs to
push the changes to the central server so that
other developers can see them. This essentially
means that viewing the history of
changes requires that you are connected to the server in order to retrieve
and view them. Now, let’s discover how distributed version
control systems work. Distributed version control
systems or DVCS for short, are similar to the
centralized model. You still need to pull code down from the server to view
the latest changes. The key difference
is that every user is essentially a server
and not a client. This means that
every time you pull down code from the
distributed model, you have the entire history of changes on your local system. Now that you know a
little about CVCS, and DVCS, let’s explore some of the advantages and
disadvantages of each. The advantage of CVCS
is that they are considered easier to learn than their distributed
counterparts. They also give more
access controls to users. The disadvantage is that they can be slower given
that you need to establish a connection to the server to
perform any actions. With DVCS, you don’t
need to be connected to the server to add your changes
or view a file’s history. It works as if you are actually
connected to the server directly but on your
own local machine. You only ever need to connect
to the server to pull down the latest changes or
to push your own changes. It essentially allows users
to work in an offline state. Speed and performance are also better than its
CVCS counterpart. DVCS is a key
factor in improving developer operations and the software
development life cycle. You will learn more about
DVCS later in this course. There you have it. You
can now differentiate between a centralized and a distributed version
control system. You also learned how they operate and what
their benefits are. As an aspiring developer, I’m sure you can appreciate
the importance of version control
systems. Well done.

Tutorial: Version Control Like a Pro

Welcome to the world of version control! In this tutorial, you’ll discover how to manage code changes effectively, collaborate seamlessly with your team, and resolve conflicts with ease. Let’s dive in!

What is Version Control?

• Think of it as a time machine for your code, tracking every change and allowing you to revisit any point in its history.
• It’s like having a safety net, enabling you to undo mistakes, revert to previous versions, and experiment without fear.

Key Concepts:

• Repository: The central hub where all your project’s code and its history are stored.
• Commit: A snapshot of your code at a specific point in time, along with a message describing the changes.
• Branch: A separate line of development, allowing you to work on new features or experiments without affecting the main codebase.
• Merge: Combining changes from different branches into a single branch.
• Pull Request: A way to request that your changes be reviewed and incorporated into the main codebase.

Common Version Control Systems:

• Git: The most popular version control system, known for its flexibility and distributed nature.
• Mercurial (Hg): Another popular option, often praised for its clean interface and ease of use.
• Subversion (SVN): An older system, still used in some organizations for its centralized approach.

Typical Workflow:

1. Make changes to your code.
2. Stage the changes you want to commit.
3. Commit your changes with a clear message.
4. Push your changes to the remote repository.
5. Create a pull request for review.
6. Address any feedback or merge conflicts.
7. Merge your changes into the main codebase.

Resolving Conflicts:

• When multiple developers modify the same code sections, conflicts can arise.
• Version control systems help you visualize and resolve these conflicts, usually by choosing which changes to keep and which to discard.

Benefits of Version Control:

• Collaboration: Work effectively with others, track progress, and share feedback.
• Tracking: See who made specific changes, when, and why.
• Experimentation: Try out new ideas without fear of breaking the main codebase.
• Backup: Protect your code from accidental loss or corruption.
• History: Reference past code versions for bug fixes, feature rollbacks, or learning.

Ready to Take Control?

• Choose a version control system and set up a repository for your project.
• Integrate it with your code editor or IDE for a seamless workflow.
• Learn basic commands to commit, branch, merge, and resolve conflicts.
• Adopt best practices for clear commit messages and regular communication with your team.

Version control is essential for modern software development. Embrace it, and enjoy the power of tracking, collaboration, and conflict resolution!

You are working with a team of developers on an app to help people work more efficiently. While you are developing this app the codebase you are working on goes through many revisions as each potential change gets peer-reviewed and given the ok. What is this system of checks that provides a detailed record called?

Version control

That is correct! Version control is the term given to the system used to keep a detailed record of all changes to the codebase.

I’d like you to think back to a time when you thought you’d lost work because it had
been overwritten or deleted. As you have previously learned, version control and
version control systems help developers keep track of their code and are
up-to-date with any changes. In this video, you’ll get a
feel for how developers use version control to keep track of changes and resolve
coding conflicts. When working with a
team of developers, it’s essential for the
codebase to have a source of truth that has all
historical changes. Version control systems play an integral part in
aiding this process by providing a full
history of changes of every single file added
to its repository. It makes collaboration
across a team easier. Also aids in working
toward a common goal. Whether it is adding
new features and following the flow of how
they were implemented, or discovering where
a potential issue may have been introduced. Being able to accurately
pinpoint the who, the when, and the what of
those changes is paramount. The revision history will record the essential data points
so any developer or team member can walk through the entire project from
start to its current state. Every change that
has occurred on the project should
be easily accessible either by a simple command or integration into the
developer’s IDE. It’s important for
organizations to define standards for how developers communicate changes they make. Developers need to know prior
to looking at the code, what the lead
developers’ aims are. The more information the better. This creates a stronger
team environment that is more
transparent and open. Now, I will guide you
through an example of a typical development team working on an
e-commerce application. Suppose you’re working
in a team with three other developers to
release a new feature, you’ve been tasked with creating a new feature to enable
experiments on the website. This will allow the
marketing department to test user behavior. A daily report is generated that ranks the effectiveness
of each experiment. The reports will give insights into how each
experiment is doing. They will then provide
the results of which experiment is the most
successful and overall winner. After commit, the developer
will push their changes to the repository and create something called a pull request. Developers will then peer review the poll request to approve
request changes or decline. When working on a
single project, there’s usually some level of crossover between
the developers. When this does occur, the history of
revisions can help aid the developers in seeing the full life cycle of
changes that have occurred. It is also essential for merging conflicts where multiple
developers have made changes that may need to be resolved prior to the
code being approved. The history will show
who made the change, for what reason, the code itself and its changes, and the date and time
of when they occurred. Typically on a new project, you will encounter
changes in one task that may cause potential issues
or conflicts with another. The history of
revisions will give the team the ability to
manage and merge these changes and deliver
the business objectives in a timely manner. Well done. You’ve now learned about
the history of revisions. Remember, it’s vital to
have a system in place to keep a record of all
changes to the codebase. This is critical when working with a team of other developers. You should now be able to
describe how developers use version control to fix any conflicts that may
occur during production.

Well done. You’ve reached the end of
this introductory module on software collaboration. It’s now time to review what you’ve
learned during these lessons. This module started with a case study
about how software engineers collaborate across the globe without
wrecking one another’s code. You then began to explore the answer to
the question, what is version control? You learned to describe how modern
software teams collaborate and work on the same code base, list different
version control systems, explain different version control methodologies, and
explored software development workflows. You learned about the history
of version control and that it has been in use before
the internet was widely adopted. You explored conflict resolution,
and discovered the important role of version control in the software
development process. You learned about some
of the common tools and strategies developers used to implement
version control such as workflow, continuous integration, continuous
delivery and continuous deployment. The differences between staging and
production were explored and you learned that the staging environment
should mimic your production environment. You also learned the many areas that
benefit from creating a staging environment, including new features,
testing, migrations and configuration changes. You learned that any issues
should be caught and fixed in the staging environment
before going live in production. You have also explored downtime,
vulnerabilities and reputation regarding production. You should now be familiar
with version control. Well done. You’re making good progress
on your learning journey