Helix TeamHub is a comprehensive, scalable code hosting and collaboration platform that is changing not only how developers work with one another, but how development syncs with other aspects of the software development lifecycle.
Join Chuck Gehman, Technical Marketing Engineer, and Ilmari Kontulainen, Chief Technology Officer, as they formally introduce Helix TeamHub and discuss why this full-fledged collaboration solution was built for today’s developer needs.
With support for multiple source code and artifact repository types, feature branch workflow, and countless integrations, Helix TeamHub is helping organizations modernize software development, scale DevOps, and achieve faster, higher-quality releases.
During the webinar, Chuck and Ilmari will delve into the following topics:
-Introduce Helix TeamHub and how it aligns with the Perforce Software suite.
-Discuss the state of code hosting in 2018.
-Explain why developers love using Helix TeamHub.
-Explore what makes Helix TeamHub scale unlike any other Git hosting tool.
-Learn why Helix TeamHub is a must have for Git, Subversion, and Mercurial developers
25. Follow us for news and insights!
Visit www.perforce.com
Notas do Editor
Rachel’s Intro
Ilmari Kontulainen
Chief Technology Officer, Perforce Software
Ilmari Kontulainen is the Chief Technology Officer for Helix TeamHub. He has more than 10 years of experience working in the software industry, in both technical and business roles. When he is not working, he enjoys competing in triathlons and other endurance sports.
Chuck Gehman
Technical Marketing Engineer, Perforce
Chuck is a technical marketing engineer at Perforce. He has worked as a CTO, architect, developer, and product leader in startups and large enterprises. He enjoys volunteering for technology education initiatives, attending Meetups, and writing.
First we’ll talk about Perforce’s Code Hosting and Collaboration Solution, Helix TeamHub. It’s different from other code hosting solutions in several ways that we will discuss.
Then we’ll get into a nuts and bolts discussion of topics that are important to Developers using Code Hosting as we head into 2018.
The topics we cover next will resonate well for anyone who is either using on-premise Git servers, or other code hosting solutions today.
And we’ll provide some insight into our roadmap as we have it planned for next year.
Then we’ll open the floor to questions.
Perforce serves the needs of product development teams in these three major categories. (speak the three)
Helix TeamHub fits into our growing product line in both the Developer Collaboration as well as the VCS and Repo Management categories.
We have strong integrations connecting all of our products to your favorite tools.
These are some of the unique attributes of Helix TeamHub.
It has features that work for the individual developer, as well as small and large teams.
I’m going to turn things over to Ilmari now, who will talk about the great benefits Code Hosting in the ever-changing environment we all live in today, and that will only accelerate in 2018.
Code Hosting is critical to fulfilling the promises of both Agile and DevOps, which is to deliver value to the customer more quickly.
Let’s start by listing the pain points that we are trying to address.
Perforce is all about scale, when we talk about scale we mean
@ Scale = Number of repos, number of developers, number of assets, number of commits, number of technologies involved
As these numbers grow, so grow the problems, such as
Role of IT, how does IT fit to the picture and how can they help
Tracking changes on features or releases that span across multiple repositories
Making the development workflow as smooth, efficient and automated as possible
Continuous integration and other automated feedback loops
And finally, Serving the developer needs as well as the organization needs
When the trend about every company being a software company emerged, we started to face a problem with IT not being able to respond enough to the pace of change
Projects are created more and more often, the needs to grant and control the access to those projects happens more and more often
Self service is a requirement, not a nice-to-have feature
Self service in code hosting and HTH in particular means anyone with proper credentials can create a project and become the owner and thus the administrator of that project
Earlier there were tickets created to IT to accomplish this and all of the related tasks
Now that person who created the project can invite others to the project
Set permissions based on roles
Create necessary repositories and the project structures
Set up the rest of the tooling around it
Everything happens with a couple of clicks
Role of IT
The role of the IT organization is becoming more and more
To enable self-service within the development organization and
Making sure the compliance and security requirements are fulfilled
Self-service actually helps in this regard as the number of “self managed” tools diminishes and
the self-service platform acts as a single source of truth
Multi-repo in single team:
Early days we were building Monoliths, software consisted of a component that was stored under a single repository
-> divide development into components, good example being dividing Backend and frontend where we already typically divide the code to two different repositories
- starting to use libraries and frameworks
-> coming to today, where micro-services architectures are more than common
- biggest percentage of code comes from 3rd party components
-> in the future, we see trends such as serverless emerging
- even smaller components
The number of code lines per component is getting smaller
The number of components is getting larger
- Various build tools used, various artifacts being produced by those build tools, need a way to store and version those artifacts
We rely overgrowing number of external dependencies, 3rd party libraries and tools
Up to today, there’s no ability to manage multiple components seamlessly
Managing both code and the dependencies under one platform is something that brides the gap between the development tools
If we then think about these problems in a larger context, we face the same problems across the organization:
We have various projects, some of them legacy, the projects have been done in various technologies and use various version control systems
Companies do more and more acquisitions and obtain the IPR, which means the source code and the dependencies
What we really need is a Single source of truth for managing the sprawl that happens. Having that single source of truth allows us to
Protecting IPR
protecting against claims
Enable discovery and reuse of software, components or even source code
Talk about the benefits of having multiple Git repos, and also artifacts and using WebDav for graphics?
Talk about code search across multiple repos
Code Review benefits:
- Fewer defects in code
- Improved communication and sharing of best practices
- Education of junior programmers and peer learning
Doing code reviews enables us to gain
Shorter feedback loops,
shorter lifetime for bugs and
- More maintainable code
- And All this boils down to is of course More customer satisfaction and less support calls
- For code reviews, we need proper tools to both conduct and store the review information
- What we need from the code review tools is:
- Easy workflow for developers to conduct the reviews
- And here I see that a ”pull requests” in which I mean a contribution outside of the project, happens less often outside of open source community,
code reviews are typically done within the same repo, across branches, not across repositories
Typical workflow is doing a feature in isolation inside a branch, there can be numerous feature branches in parallel
When feature is done, create a review which will also conduct the merge between the branches after the is done
In order to make this code review workflow efficient, we want to have multiple layers of control, before we actually merge
In HTH we can set number of approvals, the number of “other” team members who need to explicitly approve the changes
We can also require that a continuous integration tool, such as Jenkins gives a successful Build status for the feature branch
We can ensure that the feedback given during the code review gets addressed using Task comments that need to be resolved
And finally, we can set Default reviewers, that are automatically assigned as reviewers to new code reviews, we can think default revierwers as owners or guardians to a specific component
Code Hosting solutions makes setting up CI with a team much simpler
Earlier it took custom scripts or a lot of manual work to test that features work well together and not just “on my machine”
CI is the feedback loop that we build on top of the VCS.
It ties to the development workflow giving early feedback often and constantly.
It also acts as a gate keeper or quality gate during the code review process
Now, as the projects get bigger and bigger, the CI can become the bottle neck.
Especially when we are talking about projects that span across geographical locations
The problem we usually see that the clone and pull operations take longer and longer.
Usually this is tackled with multi-site replication and this is a good solution on some cases.
However, when the projects span both across multiple geographical locations, and across tens, hundreds or even thousands of repositories,
we start to experience the problems with clone and pull performance even if we use replication.
Helix TeamHub Enterprise we have solved this by creating Helix4Git
Helix4Git is a basically a reimplementation of the Git backend utilizing the proprietary capabilities in Helix version engine,
but The difference is, you can both manage and interact with multiple Git repositories atomically.
Currently this allows checkout changes 80% faster and in some cases, reduce the number of build servers required by 75%
In the future, it will allow us to do even more
We divide the reasoning to the developers as well as to the organization around them
For the developer Developer:
We have always wanted to build tools that Developers love to use, after all, we are developers ourselves
One of our key values has been Simplicity, which means getting things done efficiently
Another is extensibility, the ability to build your own tooling around the product, we accomplish this with the 100% api coverage, which means you can do everything via APIs that you can do via the web UI
Additionally, we have a lot of hooks that can trigger actions in other tools and services according to actions taken in Helix TeamHub
If we think about the organization as a whole:
We strive to deliver our promise of a Single source of truth, where all the assets, both code, build arfitacts and other digital assets can be found from one place
This ensures that the Compliance and security requirements are met and that the IPR are safe.
Possibly delete SVN to Git
This is a problem that is not necessarily being solved by your code hosting solution today.
In fact, it probably isn’t.
Let’s take a look at how HTH solves for this.
Helix TeamHub Enterprise includes Helix4Git as an important feature that gives customers the capability within the Helix Versioning Engine to handle Git
TeamHub can manage any number of Git repositories and store their whole history.
Internally we use a data model similar to Git.
The data model allows Git clients to work against the Perforce server, without even knowing the repository is actually in Perforce.
This delivers several Git at Scale benefits:
Simplify the build process and manage complex projects by organizing multiple Git repos
Get the code and build assets into your DevOps pipeline faster than possible with native Git.
Improve performance for remote sites, by acting as a proxy/cache. This can speed up many activities, such as cloning and copying.
Bring all your Git assets into the Acclerated DevOps pipeline, even from other repos
Git has scalability challenges, but HTH removes the boundaries, with dramatically better build performance in environments with many and large repos.
Implement a seamless product development workflow that incorporates assets such as large graphics and binaries, in addition to source code.
This breaks down the silos of traditional Git storage; so files from one Git repository can be mapped with files from another Git repository as well as depots in Perforce Helix Core
Three cloud versions: Free, Standard and Premium. Free is for up to 5 users, and includes 1gb of storage per user. Standard is for 6+ users for $19/users/year and adds email support. Premium is $29/user/year and adds SSO, Repo and Branch-level authorizations, Code Search and Collaborator accounts. Enterprise is $179/user/year and adds HA/DR and Higher Performance Build with H4G. YOU CAN SEE THE FEATURE BREAKOUT and pricing on Perforce.com
Going into 2018…
HTH is the only code hosting system today that supports multiple repos with a project structure, and also multiple repo types in a project
This includes Artifact Repos.
Doing these workflows on top of the multi-repo project, connecting it all together.
Talk about the artifact Management.
---
Let’s talk about what that looks like:
Multi-repo workflows with Git, and in Hybrid.
For example, with Git- Imagine Code Review across repos.
Managing the branch explosion across multiple repos.
Manage the integrations across multiple-repos, not just individual.
Or even a slice of the Repo.
No one is doing this, everyone is 1:1 repo to webhook.
The binary problem is solved completely.
Microsoft’s Git GVFS. Solves the large repo situation, i.e., the whole Microsoft Windows code base inside one repo.
You lose offline access, and potentially other barriers to workflow.