Plastic SCM 2018 backlog
I'm writing this for the core users like you because we want to share with you what we are working on and what we are busy with, so you can be on the same page as us. I engage in conversations with hardcore Plastic SCM users like you weekly, if not daily, and I find myself sharing some of our ideas on a one-to-one basis. But, I think having a blogpost putting it all together and sharing the global vision can really help create even better interactions with all of you.
So, here it goes, this is what we have in the backlog for 2018.
As you can imagine, I'm just putting the big blocks here, the strategic stuff. Beyond that, there are tons of smaller tasks (although important) that we deliver release after release.
Color codes
The colored boxes (except two of them) mean that the area belongs to more than one group because it contributes to more than one big strategic goal.
The big blocks for the year
Here are the big blocks we considered for this year:
- DevOps: Yes, it is a buzzword these days, but beyond that, we think we must ease the interaction with CI systems to really make branch-per-task and Plastic really shine.
- Games/per-file development: There are many users who need more "flexible" workspaces, sort of a mix of Gluon-mode with regular Plastic.
- Cloud: It is one of the Plastic cornerstones and we have a bunch of ideas to make it even better.
- Onboarding: Probably not super critical for you as a core user, but it is something we need to work on to make newcomers feel at home.
DevOps
As you saw in the blog, we are improving all things related to delivering task branches faster. We changed our internal way of working (evolved it in reality) last year, and we realized if we wanted other teams to really get the best out of Plastic, we needed to make it much easier for them to integrate with CI, test automation, delivery and so on. Yes, many bigger teams out there using Plastic already do all that on their own, with triggers, scripts and so on, but it is a lot of work for a smaller group.
All the areas in this group are here to make it easier to integrate with CI tools and implement a mix of branch-per-taks + trunk-based dev + automated testing + automated delivery.
- Server-side-merge: Already delivered. Basically merge-to on steroids. Now with full conflict resolution. It is key to automate the merge process in Plastic. We considered it delivered although there are some cross-cutting features with mergebot that are yet to be delivered.
- Writable Plastic Drive: I have been dreaming about this one for years. I would say the two things I wanted back in 2005 were semantic diffs and this. We have a readonly, Windows-only, filesystem driver that lets you browse changesets on a Windows drive. Our long-term goal is to make it writable (so workspaces end up being cleverer), move tracking becomes super precise, you can't write to a non-mergeable file without locking it first, and you only download files on demand (transparently). And many more. The only reason why we didn't do it 5 years ago is because we were busy. We still are. But, it is time to make this one happen.
- Distributed locking: I'll describe it in the next section.
- Code review: Well, we have like a 10 pager with suggestions for the built-in code review. When we first developed a code review and put it inside Plastic we thought "Well, who's going to use it if there are specific code review solutions on the market?" It was super simple. To our surprise, teams used it. This was before the days of GitHub pull-requests and all that. We were there before, but we failed to understand that users wanted simpler tools, not full-featured/super-complex code inspection tools. So, we need to catch up here. You requested lots of improvements and made lots of suggestions. We also have very good ideas on how to make code reviews shine… it is just time to code it.
- Review CI integrations: We have been delivering improvements for Bamboo, TeamCity and Jenkins already. The goal is to implement a fully automated branch per task cycle with each of them, with the CI driving the merge. At the time of writing this, we fully delivered it for Atlassian Bamboo (even made a webinar), and we are about to release the same for TeamCity.
- Multi-file semantic merge: Yes, we are going to embed SemanticMerge in Plastic (as we did for semantic diff) and it is going to be able to merge methods moved across files. We already have all that implemented, it is just a matter of packaging it into Plastic.
- Mergebot: This is the game changer. This is really our vision for DevOps, so it probably deserves a blogpost on its own. I'll try to write that soon. Until then, suppose it is Plastic that is doing the merges of the task branches when certain conditions are met (like the task has been reviewed, an attribute properly marked on the branch, and the associated Jira issue has a given status). We are in the perfect place to drive the merge process, better than the CI system. Then, Plastic will push the merged task to the CI system to be tested (testing the *real* merged code, a huge difference compared to many approaches out there), wait for results, and confirm the checkin if everything goes well. This is what the mergebot is about. It is based on the "server-side-merge" because we want to do workspace-less merges. This is one of the greatest features we have for this year.
- New WebUI: Ever used the old one? Not bad, but it is hard to install. It comes in a separate package, it depends on having Apache or IIS. A pain. The new one is fully based on JavaScript (so thick client-side app on your browser), it is transparently installed with the server (same technique we used for the WebAdmin), and it will be the basis for our new code review system, so it will be available on all platforms from day one.
- Evolve git server: We need to support SSH, make it faster, and move the git mappings to the server side. Ideally, we'll also make Cloud support it, for greater interop. Not an easy one, though.
- Web 3-way merge: Yes, like the perfect companion to server-side merge; suppose you trigger a merge from the WebUI, there are conflicts, but you can merge them from the browser, using semantic merge and everything. That's the goal.
Games/per-file dev
Plastic is super strong in games. I mean, it is not where our biggest customers are (we have +1000 users in other industries), but we get a lot of traction here. It is super natural for many game teams to abandon Git and come to Plastic SCM because of the locks, the huge file support, Gluon and a few others.
But, we also get a constant flow of ex-P4 teams coming to Plastic. They come for the better branching and merging, and the true distributed, but they are very, very used to a per-file mindset. For example, I want to checkin this file but not update my branch to latest when working centralized. We support this with Gluon already, but many teams need to have artists and coders on the same repo and have mixed environments. And, as I said, this is not just for games. Automotive, insurance, healthcare… all interested.
So, what are we doing to make it better?
Server-side-merge and Plastic Drive were already covered under DevOps.
- Distributed locking: Or travelling locks. For example, I want to lock this file on main/task127 but only unlock it when it reaches main (otherwise, as it is today, the lock is not useful unless you are on a single branch). This enables branching for teams with lock restrictions (unmergeable content). It goes even further: I lock it, but it should only unlock when it reaches main@centralserver. Awesome, isn't it? Game devs love it, but micro-electronics teams too.
- Per-file merge single branch: While in Gluon you normally work with unmergeable files, there are cases where game designers use text scripts and would greatly benefit from merging. We can implement a per-file merge without merge tracking for merges on the same branch. For example, you are working on something, then someone else make a change on the same file and checks in. Now you go to checkin and need a merge. We can correctly resolve the merge (with the correct ancestor) but solve it without setting a merge link (which is not possible because the workspace is in partial mode, and hence not synced to a given changeset). Our goal is to add this option when working in full-plastic too, for cases where you just want to merge on a single branch without merge tracking to keep the branch cleaner (hopefully it won't be used for evil!).
- Partial tree branching + replica: This is about creating branches which root in a subdirectory. There will be some restrictions to merge them (like only merge to parent branch to avoid nasty cases). They are useful to share part of your code with a third party; you branch partially, push to a different repo, then share the repo, or just give access to this branch, or even push the smaller repo to GitHub for collaboration.
- Smoother partial/full transition: So that users can work on a partial workspace, then seamlessly switch to a full one (make it easier than it is now). It is also about enabling the regular Plastic to deal with partial workspaces, or even handle mixed workspaces (where part of it is partial and part full). It should bring the combined benefits of full + partial workspaces. Like the "art" subtree does not need to be downloaded to checkin, while the code subtree behaves normally.
- Pruned trees: Rules to easily allow trees to be pruned so that you only download parts of it.
- Grafts in trees: To inject a subtree into another in the workspace for greater flexibility. For example, you are on a branch and want to test it combined with another one, but without merging, just injecting the changes made in the other branch into your tree.
- Improved Unity workflow: Many studios using Plastic also use Unity. We already made a plugin, and several improvements, but we feel we need to go further and explore more improvements. It will obviously benefit from features like "distributed locking", but we have a list of new things too.
I don't want to get too much more technical, but the key feature behind pruned trees, grafts, partial tree branching, and smoother partial/full transition is "server-side merge". We could do magic in workspaces just altering trees. But, when merge enters the scene, things get complicated. By merging on the server side when needed, on a super clean tree (no possible local modifications), we can allow users to do whatever they need in their working copy, with the confidence there always be a way out to solve merges.
Cloud
Plastic Cloud is quite unique in terms of the type of projects it can handle. The average repo in Plastic Cloud is above 15GB. And +100GB repos are not rare. Plastic Cloud is the place when things go big.
Since it is an important piece of our business, we will be investing more into it.
- Plastic Drive: To optimize downloading big workspaces by reusing content.
- Blob removal: Right now, we can't easily remove blobs from the Cloud. No excuses.
- Code review: The goal is to make it available on Cloud, eventually.
- Webhooks: We don't have triggers for Cloud yet. We must.
- Performance: This is not as much a goal as a journey. We are always making it better. We have some ideas to take further advantage of the underlying native cloud infrastructure we use.
Onboarding
Last, but not least, we need to improve onboarding. This is probably something you don’t care that much about if you are a power user, because you are already familiar with Plastic. But, for newcomers, we do need to make some things simpler: from empty states, to UI clean up, to bringing more features into the Linux and OS X GUIs.
- plasticscm.com evolved: Shared with Cloud. Renewing licenses can be easier, signing up, accessing the forum, login to support… we need to remove some rough edges here and there.
- Usage metrics: To actively improve the product based on data and to know what the most useful features are. We need to get better in this area.
- Plastic SCM book: A compilation of writings sharing the underlying philosophy of the product and how to make it shine. Long ago most of our user guides were almost references, quite uncomfortable to read. We switched to a more informal style focused on problem solving more than abstract descriptions. But, the guides are still more about how to use this or that, instead of helping users implement best practices. This is what we want to fix by writing our own book.
- UX improvements: Like the ones I mentioned above: cleaning up the UI (we already started with that on Windows, which is the older of the three), simplifying actions, removing unused features, adding empty states to explain each view, etc.
Wrapping up
As you can see, we have a busy year ahead. We release very frequently; it is not strange to have 2 new versions every week, so expect to see the list above being completed version by version.
Of course, this is the strategic backlog, the key things. But, there are tons of small modifications, fixes, feature requests that, while important, don't have room on a high-level list. But, they are addressed, release after release.
I hope you find this backlog as exciting as we do, and we are eager to read your feedback!
0 comentarios: