Can we use Plastic Cloud as issue tracker server?

[David Yang]

Hey guys

Loving Plastic so far. Pretty much the only thing stopping me from grabbing a Plastic Cloud subscription or the Cloud Edition right now is the issue tracker integration.

I'm currently a hobbyist / solo developer but work 50/50 between two computers on different networks, so Plastic Cloud would be really handy for me (I'm used to the world of Git repo hosting, where I don't have to worry about server setup and maintenance). But if I have to set up a server for the issue tracker anyway... well that kind of defeats the purpose for me.

So, wondering if any of the following options are planned for the near future (or already included and I've just missed it):

• Ability to use Plastic Cloud as the server for one of the free issue trackers (eg, MantisBT). That would save people like me from having to pay for Plastic Cloud + pay for server rental or another cloud service for the issue tracker.
• Or even better, if Plastic Cloud came with the issue tracker server already set up and integrated, so we could just use it out-of-the-box like with most Git hosting services. Setting up and using Plastic SCM has mostly been a fantastic and painless experience, but the same can't be said for trying to get a free issue tracker up and running.
• An issue tracker extension for Github, Bitbucket, Azure Boards (part of Azure DevOps formerly VSTS) or one of the other free web-based issue trackers for Git repos. (Yes I realise I can create my own extensions, but only if by 'can' you mean 'theoretically possible' rather than 'realistically able to'. Also would sort of defeat the cloud convenience factor.)

Anyway, look forward to hearing back from you on my options. Really loving Plastic SCM and keen to get started properly as soon as possible.

Kind regards

David

 

PS: on a slightly unrelated note, if I get Cloud Edition (or cloud extension with Personal Edition), that still comes with a localhost clone so I can checkin/branch locally (quickly) right? Also, if I get Cloud Edition for now but want to switch to Team Edition on-prem server in future, I can do that without losing any data right?

[psantosl]

Hi David,

 

Thanks for reaching out, and sorry for the delay, but we were discussing the solution internally.

• As far as I know, there shouldn't be a problem to connect your Plastic with a Mantis. Remember that the "integration" happens on the client side, so there will be the same integration whether you are on Cloud or on-premise.
• Built-in issue tracker: believe it or not, we have our own internal issue tracker !! You can see some screenshots here: 

And here a more recent one  just taken:

But yes, it is not meant to be a production issue tracker. We've dreamed about making it public, but... well, too much work. We struggle with Plastic already, so I don't think we'll be adding TTS (that's its name) soon to the pack. (Now who knows if I'll be eating my own words soon :P)

 

• Integrating with others is of course an option. We do integrate with a number of them: Jira, Bugzilla, and a few others. And... you can develop your own integration in almost no time: https://www.plasticscm.com/documentation/extensions/plastic-scm-version-control-task-and-issue-tracking-guide#WritingPlasticSCMcustomextensions

 

Hope it helps!

 

 

 

[David Yang]

Many thanks @psantosl.

Quote

As far as I know, there shouldn't be a problem to connect your Plastic with a Mantis. Remember that the "integration" happens on the client side, so there will be the same integration whether you are on Cloud or on-premise.

Just want to make sure I understand this (sorry if I've got this wrong, some of this is still new to me). While the "integration" is client side, most of the free issue trackers require a server to host the issue database so different computers can access it (similar to how Plastic requires a server to host the repo database).

Now for those who already have an on-prem server or a VPS, that should be fairly easy (can just use the existing server for both Plastic and issue tracker). But for someone like me who comes from the Git universe and doesn't already have on-prem or VPS, if I decide to use Plastic Cloud as my Plastic server, I would still need to set up another server to act as the issue tracker server.

Does that make sense?

Wouldn't that sort of defeat the benefits of choosing Cloud Edition (ie, convenience and not having to deal with server setup/maintenance, etc)? Also from a cost perspective, I would then need to pay for 2 servers (Plastic Cloud + separate issue tracker server), even if for example I was only using 1GB out of my 5GB Plastic Cloud allowance.

Quote

And... you can develop your own integration in almost no time     (emphasis mine)

Ahh, the curse of knowledge 🤣. This may very well be true for yourselves and a lot of your existing customers. But I bet for many people like myself, it would involve learning something we've never done before and take quite a bit of time (please remember, even server set up was new to me coming from the Git world!!)

Not insurmountable, but just one more "barrier" for Git users to make the move to Plastic 😉

Quote

We've dreamed about making it public, but... well, too much work. We struggle with Plastic already

Yeah, this is a tough one...

I recently read your blog about all the new features on your roadmap (http://blog.plasticscm.com/2018/04/2018-backlog.html), so can understand when you say too much work. You know your product/customers and priorities best. But if I may offer one suggestion and possibly a different perspective to consider:

I really love Plastic (as I'm sure you know by now), but have to say I've struggled at times with the move from Git to Plastic (and that is with a relatively small and unimportant code base without significant time pressure). It is not the UX or lack of a Plastic SCM book which has made onboarding hard at times - it is things like having to learn how to set up a server, having to research cloud compute and VPS options, having to set up a new issue tracker, thinking about whether I'll lose anything I care about when making the move (eg, open issues and pull requests / code review comments).

Might sound trivial to you guys, but these were things which were completely new to me and had to learn in addition to a new SCM tool. 

The planned features to make workflows even more flexible sound nice, but even without those, Plastic is already so much more flexible than workflows possible with Git. It is really great to see you focusing on new features for your existing customers, but as someone who would love to see more people using Plastic, perhaps it's also worth thinking more about the current "barriers" that discourage potential new users?

For example, see this forum post from another Git user, who says he thinks Plastic is one of the best VCS's but "learning a new toolset and switching the whole organization workflows is not something we can afford to do just to gain a few extra features". Perhaps Plastic's core features are already good enough, so it is no longer about adding more and more flexibility/features to attract new users, but more about making migration easier and less disruptive for new users (not just for migrating the repo itself - which you've already made easy with GitSync/P4sync - but for associated stuff like issue tracker and code reviews)?

[David Yang]

Update 24 Jan:

Found a potential solution. Just found out that FogBugz (now called Manuscript) is free for up to 2 users with free hosting on their servers. It's pretty hidden though - they don't seem to advertise it anywhere on their site except in the FAQs - which makes me a bit nervous about whether they intend to keep offering it. The next step up is $75/month for 5 users 😨

As long as the free offer remains though, it would be a viable solution alongside Plastic Cloud (for those who don't have on-prem / VPS). Personally though, I am probably going to stick with Azure DevOps' issue tracker (I prefer its simplicity) and just live without the integration or ability to link issues with changesets/branches. Or go old school and just use a spreadsheet.

(Reason being that I really dislike having my data locked into a proprietary format that requires an ongoing subscription. So far Plastic SCM has been my one and only exception because (a) it is so much better than everything else that I'm not worried I'll want to move to another product in future, and (b) worst case scenario I could always push my Plastic repos to Git - though the only conceivable reason I'd ever do that is if Plastic became crazy expensive, but you would never do that to us right 😘?)

But thought I'd let you guys know about FogBugz in case it helps anyone else.

David

 

@psantosl - I still stand by my above comments btw. When you guys are ready to take the fight to Git big time, I honestly think having an issue tracker you can use out-of-the-box with Plastic would be a big thing for all the Git users who are used to having one built-in to their Git hosting service. Being able to "one-click import" open issues would also be a big selling point, I'm sure. (You'd only need to support importing from the major Git hosting sites too - eg, GitHub, BitBucket, Azure - since those are the people most likely not to have their own server or standalone issue tracker).

[psantosl]

Issue tracker has been one of our secondary projects for a long time... never know if we'll ever make it public though

[David Yang]

Señor Pablo - are you trying to get my hopes up by bumping this old thread? 😜

You will not believe the roller coaster ride I've been through these past few days trying to get a good issue tracker up and running alongside Plastic (it's kind of necessary for the task branching workflow you keep banging on about!)

• First got excited about your Spanish compatriots at HacknPlan (which you could probably tell from my rambling email) - linking tasks directly to the design model seemed like a really neat idea (and good way to keep the bigger picture in mind while picking away at tasks)! 📈

• But after using it a bit more, I realised it was still pretty "new" and missing some important features, which made it difficult to use it for maintaining several small projects... 📉

• Then discovered Confluence - which combined with Jira would also allow organising tasks under a design document tree. And only $10+$10 perpetual license for self-hosted small teams! 📈

• So tried setting up an entry-level Azure Windows VM, and almost gave up because it was unbearably slow (even with nothing installed and full bursting credits)... 📉

• Then someone suggested I try AWS instead, and the comparable entry-level Windows EC2 instance was pretty snappy! Installed Plastic SCM no problems and even working centralised (direct checkins) was pretty fast! 📈

• Then tried installing PostgreSQL + Jira + Confluence and it absolutely crippled my EC2 instance. Oops, forgot to check the system requirements for Jira + Confluence. They need HOW MUCH RAM??? EACH?? Checks price for an EC2 instance with that much RAM... 📉

• As a last attempt, learned how to set up a Linux EC2 instance with SSD swap file in hopes that maybe that would work better. Get a minimal GUI and XRDP remote desktop running in Centos despite never having used Linux before - pretty chuffed! 📈

• Then tried installing chromium so I could use web admin tools. Takes several minutes to load. Uninstall and try Firefox. Same... (What? I thought Linux was meant to be lighter and faster - even Internet Explorer on Windows server was very fast and responsive...) 📉

• (Seriously contemplated going back to one of the all-in-one Git solutions and just getting on with my life...)

• (... but I like Plastic too much 😔)

• Finally this morning found Jetbrains' YouTrack. Similar to Jira in many ways but easier to setup and "only" needs 1.5GB RAM. No Confluence-style linking of tasks to design model, but self-hosted version is free for small teams and at least on my EC2 instance it's... responsive. Kind of. Is this the answer then? Time will tell.

 

If you thought that was painful and long just to read... (you and your branch-per-task workflow *shakes fist*)

So as you can see, surprisingly, by far the hardest part of moving to Plastic SCM isn't directly related to Plastic at all! Plastic Server was an absolute breeze to get up and running (thank you btw for making Plastic Server so easy to set up and so gentle on system resources!! Why can't all software be like this!)

 

PS: But yes, despite the above, also starting to realise why you wanted to focus on SCM and not have to worry about maintaining an issue tracker product. Such a saturated market these days!!

[psantosl]

Hi David,

 

Why don't you give a try to the hosted Jira? You don't have to setup anything, which I believe is a great burden you can avoid 🙂

 

Regarding the issue tracker use, I'm going to share my own experience (I should write a blogpost). I think I am some sort of issue tracker hermit 😄

 

• I normally don't even use the issue tracker integration in Plastic.
• What I do is to go to my issue tracker, pick up the task, then create a branch manually as follows:

 

 

The only link I normally use is the "naming convention". You know SCM24074 is task 24074. That's all. We have done +24k tasks this way over the years 😄

 

I mean, I know it is an extremely simplistic approach, but what I love is that it is so vanilla, so simple, so bare, that it always works and you don't force anyone to go through integrations or anything.

 

I mean, I do my checkins from the GUI, not from a plugin, so I might be a weird kind of programmer or something, but I really, really like to keep things super simple.

 

[David Yang]

Hmm yeah, you're right. Simple is best. I got drawn in by the prospect of a cheap/free perpetual license - which would have been really nice - but it's getting to the point where I just need to pick something... anything... and just get a move on!

Do you mind me asking how you organise/track tasks in the context of a bigger picture design goal? What I mean is, take for example your designs for the new code review system - now obviously that would involve a very large number of bite-sized tasks to implement incrementally. How do you (a) make sure people keep the overall vision in mind while chipping away at the individual tasks, and (b) track progress of the overall feature?

I'm not sure what you think of this article, but I stumbled upon it while looking into issue trackers, and that's what initially got me excited about using either HacknPlan or Confluence+Jira. Both allow you to create a moving/living design vision by organising pages (which could contain anything from detailed requirements to UI mockups or just rough notes/ideas) into a tree. Then you can link tasks to those design pages, so people working on a task can easily see how their task fits into the bigger picture. And similarly the design page shows the live status of all linked tasks so you can quickly get a feel for how the overall thing is progressing.

It's this bringing together the macro and micro that has me a bit stuck. If it wasn't for this, to be honest I probably wouldn't even be thinking about something as powerful as Jira. Almost any issue tracker would do - heck even google docs would do! (As you say, Plastic works well just using "naming convention" for tasks/branches, and the benefit of simple vanilla is that it always "works" without having to maintain software/subscriptions/plugins/etc!!)

[psantosl]

Hi David,

 

Well, this thread now should be a good basis for a entire blogpost on the topic 🙂

This is what we do:

• For super small things, just a task that gets fixed and released asap. Nothing fancy. This is true for many of the tasks that enter our releases on a weekly basis.
• For big things we try to keep a full list of what needs to be done, and, we don't use the issue tracker for that. I was never comfortable with that approach. We create a list of everything that needs to be done (in a text file, an excel, whatever) and then start assigning a task number (enters the issue tracker) to each line as soon as we know we are going to really implement it. (This avoids wishful thinking and creating things that at the beginning sounded good but then never get implemented). Probably using an external list for this is pretty cheap, and we'd enter everything in Jira if we used Jira... but since our issue tracker is so simple, we simply don't do that. We toyed with the idea of implementing a way to group tasks, but to list things to be done... well, a list is better.

That being said, last September we switched from Scrum to Kanban. We've been on Scrum for 13 years. It was sort of pure at first and then it decayed into something different. And then we decided to switch. And it has probed to work since: cycle-time (time from task open to merged and ready to deploy) was cut in half (from 9 days to 4.5 average), and everybody gained a more "team centric" vision. The contrary wasn't an issue with Scrum but us (or me). But the reality is that we changed.

We were very, very focused on individual efficacy: avoid noise, avoid interruptions, everyone working on his list of tasks for the sprint (2 weeks each). But it had a downside: you prefer to "finish your list" instead of helping someone else. We changed that.

We introduced a kanban board with work in progress limits (WIP limits, to me, the actual reason to use kanban, better than the panel):

We use realtimeboard, so no, we don't use a tool that automates stuff or anything, we simply put stickers on a wall as we'd do manualy on a physical board.

So, we can only have 13 tasks in implement (except lock, that doesn't count), 2 in review, 3 in validation. If you can't enter a new task because the panel reached the limit (13), then you have to review or validate.

And this is good, because you don't focus on "your list" but on team progress.

Of course, our hard-earned efficacy skills mean we try to be as good as possible on avoiding interruptions (we almost ditched Slack in favor of Basecamp, we don't use email for internal stuff but record everything in Basecamp, etc), and distractions and so on, but now with a sense of achievement when we move work forward.

 

Now, onto your question: how to keep an eye on the big thing? This is what *I* do:

1. You can have a column with things to do for a big project (check the "unity" column on our kanban board).

2. You can have a cheap list.

3. It is the product manager or project manager job to make sure what we are doing is really adding value.

4. Frequent messages and communications to make sure we are on the same page (with a clear roadmap document, vision docu imagining the short term future, etc).

 

I assume next question will be: how do you know N given tasks belong to the same project or big feature? I'm afraid my answer is going to disappoint you: just put a prefix. Look:

 

 

And

 

And this is how we do it. I don't mean this is the perfect way for everyone, but it works pretty well for a team our size 🙂

[David Yang]

Hi Pablo

Thank you very very much for taking the time to share that. Lots of good wisdom 🙂

You make a very good point about not assigning task numbers / entering into issue tracker too early. In that case, I guess it is not much more work to enter the task number manually into the planning document/list once ready, since the plan will probably need to be updated to reflect the current thinking anyway.

And yes, I guess you could just sort/filter tasks by a custom field or prefix to get the list of tasks for the big feature/thing. (Nothing wrong with prefix btw 😜! When I was using Azure DevOps, I also just used prefixes like [bug], [feature] or [doc] instead of using a different work item type for each type of task.)

The "live" updating of tasks with Confluence or HacknPlan is still nice, but on the other hand as you say, something simple and vanilla has the advantage of just "always working" without extra setup. I might have a play around with OneNote for design/planning instead - I've never used it before but looks like you can organise pages like wiki and collaborate both real-time and offline. And it has the benefit of being included free with Windows, no setup needed...

(I used to hate all the bloatware that comes with Windows so I had uninstalled OneNote without trying it, but maybe I should have given Microsoft more of a chance - been playing around with Edge browser recently and it actually has some pretty nifty features! I'm typing this in a Windows Defender Application Guard sandbox right now - not because I think your forums are dodgy and malware infested, but because I'm playing around with a fresh OS install and haven't installed antivirus yet 🙂).

Thanks again for all your help and suggestions!

(PS: While I'm picking your brain, I also had a quick question about your blog post on checkin with reviewers in mind, but I'll post that to the blog comments. Thanks again!)

[David Yang]

Hi Pablo,

Was revisiting this thread because I was helping another member, and just realised the question I had about "checkin with reviewers in mind" didn't seem to get posted to the blog (I think it got lost in the approval process somewhere).

Was still hoping to pick your brain on that if you don't mind? 

Anyway, the question was - I really like the idea of methodical checkins, but I find in practice I often don't "get it right the first time". Eg, sometimes I won't realise until after a few checkins that there is a problem with my approach, and I have to change course a bit, etc. I've come up with a few ways to deal with this, but each have their issues:

1. Don't checkin until I'm almost finished with the task and sure that everything works. But this kind of defeats the purpose of "checkin often".
    
2. Checkin often, and if I make a mistake or change my approach, go back and edit the comment in the original changeset so it's clear that the approach has changed, etc. This works if I'm working centralised (which I've started doing because of this), but push/pull doesn't handle editing comments well as I mentioned here: https://forum.plasticscm.com/topic/21698-love-the-recent-changes-some-thoughts-and-suggestions/
    
3. "Checkin" often, but use temporary shelves instead. Then, when sure everything works, recreate the steps and checkin properly. But this approach creates a lot of rework for the times that I do get it right the first time (which is hopefully, more often than not).

So was wondering what you guys do? Or perhaps, you've all gotten really good at just getting it right the first time?

I was reading the most recent Release Notes about the new Incoming Changes feature, and it sounds like you might already have the code to allow some basic "rebasing" even when working centralised. Perhaps you could leverage that somehow to allow people to amend/rebase/combine changesets on task branches before submitting for code review (to reduce the pressure to get things right the first time)?

Obviously it wouldn't be a good idea to allow changing history on main branch, but often only 1 or 2 people work on any given task branch. So perhaps there is a way to "lock" task branches for editing (at least those that don't have merge links), so that you can do whatever you want to your task branch without affecting other people and their task branches?

Best,
David