I think Slack notifications are really nice to see what's going on right now but not so great to see the state of dozens of service, i.e. what version is deployed to what environment.
Then there is the issue of linking the Git release/tag with the corresponding changes, say from a ticketing system such as Jira. That can be helpful to communicate changes to other people within the organization and to users.
How do you define dependencies for releasing new versions to service? Likely going to happen at some point when you have non-trivial changes to services.
> I think Slack notifications are really nice to see what's going on right now but not so great to see the state of dozens of service
Completely agree, that's why we instrument our releases so we can easily see what's deployed by service and environment.
> Then there is the issue of linking the Git release/tag with the corresponding changes, say from a ticketing system such as Jira. That can be helpful to communicate changes to other people within the organization and to users.
Each commit is related to a ticket, helps generate a changelog.
We enforce a lot of things in each of our release. We have an internal release tool heavily inspired by shipit from Shopify. We have the concept of soft/hard checker to make sure it won't break or that you aware of what could break with the current diff.
> How do you define dependencies for releasing new versions to service? Likely going to happen at some point when you have non-trivial changes to services.
As I said we instrument our releases and can easily track how changes affects our performance/bugs.
We also try a lot not to release non-trivial changes in one big release by doing stuff like release part of the changes behind a feature flipper first or route only a part of the traffic to the new code path, ...
Then we don't have dozens of different services deployed and we're still a relatively small team (~20) so I'm pretty sure I don't have the full picture just yet :)
Thanks for adding more color to your original answer.
I like you enforce the commit/ticket relationship. Is this purely an agreed process or do you use other measures to keep things consistent?
E.g. we typically add the ticket ref to each commit but at times that gets omitted.
Also, I think that (internal) release tool is something crucial as the team grows. Will check shipit a bit further.
Would you mind expanding a bit on the things you enforce for each of your releases?
> I like you enforce the commit/ticket relationship. Is this purely an agreed process or do you use other measures to keep things consistent? E.g. we typically add the ticket ref to each commit but at times that gets omitted.
We're not enforcing it but we might in the future if the team grows and this gets out of hands. At the moment we're just reminding people that they should and it works great so far.
> Would you mind expanding a bit on the things you enforce for each of your releases?
It's still early but so far we check:
- it's not friday afternoon, we want to avoid as much as possible to have issues on the weekend
- it's not out of office hour - we're still all on the same time zone
- there's no lock (we can lock the release in case something goes wrong)
- there's no schema migration. If there is we remind you how to safely migrate schema and who to ping if you have a doubt (usually it should have been caught at the PR review)
- there's someone from the ops/core team around (connected on slack)
- that there's no translations missing for our main languages (french/english)
- + we do a few sanity checks like that our master staging is healthy (release means promoting our master staging)
Thanks for sharing your thoughts on this topic. It's a challenge for all SaaS products I believe but yes, the more business critical the product the more important to address.
Apart from self-host and open source, do you have other suggestions on how to address this on a product level? Would you feel comfortable with structured exports for example?
Check out www.enterpriseready.io to get a deep understanding of the standard features that enterprises require (ie SSO, RBAC, audit logs, on-prem deployment, reporting etc). Happy to talk through any of the features, I contributed about 80% of the content. We also built Replicated.com which powers the on-prem delivery for other applications like Travis CI, npm, CodeClimate, Circle CI and a bunch of others. We think about these problems all the time and how we can best help solve them. Happy to share what we've learned there as well.
Enterpriseready is a good site, agreed. I'll also check Replicated to see how you support on-prem and would gladly take your offer to hear more about your learnings.
Structured exports are certainly better than nothing, but it doesn't address having to find and import to another system (which won't have all the same features) and retrain all staff.
Honestly this is a hard problem and something of a catch-22: the more useful the product is, the more it gets used, so the more critical it becomes, and as a result the pain goes higher.
A long track record of business, knowing if the company is profitable vs burning through VC cash, and some type of SLA and guarantee of minimum shut down notification time could all help lower risk. I don't really have any other product suggestions, unfortunately. My feeling is this is not really a technical problem and so probably doesn't have a purely technical solution.
May I ask what makes Confluence look more professional from your perspective?
Like I mentioned somewhere else, I actually like using Confluence depending on the use case. It tends to require much more attention in making sure things stay organized and well structured. Shelf has this built-in by being more opinionated (for better or worse, depending on what you need).
Thanks for taking time to try out Shelf! And for providing your feedback as well.
Tags: delimiters are [comma], [enter] and [tab]. 50 tags are the max. 30 characters are the max.
We'll see how we can make tagging a better experience. Including suggested tags based on content/previous behavior.
Can you explain what you mean exactly by: expiration on items?
Nothing goes stale faster than documentation. What I'd like to see is that when someone adds documentation he/she also adds an 'use before' or 'expires on' date.
So that folks coming after them know that the docs are probably no longer valid.
I see how you could come to that conclusion. At first glance, yes similar. However, Confluence really is a Wiki on steroids. Great to link with Jira, collaborate on Specs or the like. You can use it for document storage but not what it's built for. We use Confluence internally in the Dev Team ourselves and for that it's great.
Shelf is for curated content, not direct collaboration or Wiki. For that, we integrate with what was built for it, such as Google Docs.
> Find, organize, and share your distributed team's most valuable content
...
> Compared to Confluence: cannot create editable wiki pages, cannot "Build an Internal Wikipedia of company knowledge" etc.
Erm. How is this tool helping to "Find, organize, and share your distributed team's most valuable content"?
I currently work at an organization with over 2000 programmers and engineers. They would laugh at your face if you told them they cannot write free text in the "Knowledge management tool".
All good. That's not really the use case for Shelf. You'd publish final versions of deliverables on Shelf, not necessarily your whole work-in-progress.
Just to share a different perspective, not even to disagree with your view: Think of a marketing team that wants to publish and share presentations to be used by sales reps. Or a team of researchers that wants to curate different types of information (docs, links, videos) for later perusal. Enrich each of those with meta data. These are different use cases, that's where Shelf shines.
> That's not really the use case for Shelf. You'd publish final versions of deliverables on Shelf, not necessarily your whole work-in-progress.
Hint: It's not just work-in-progress.
Hint 2: Everything changes
> Think of a marketing team that wants to publish and share presentations to be used by sales reps. Or a team of researchers that wants to curate different types of information (docs, links, videos) for later perusal. Enrich each of those with meta data.
Yeah. Perhaps.
Still there are plenty documents which are not "work-in-progress". Onboarding instructions. Delivery checklists. Descriptions of system and organization components. Policies. Roadmaps. Guidelines. Manuals. etc. etc. etc.
I see great value in a "manage all your things in various accounts" tool. I wouldn't go as far as call it "manage knowledge of your distributed teams". You need to be able to also create knowledge inside the tool.
Because if you need to drop out of your management tool all the time to create anything, you will end up using Google Drive if all your docs are in Google Drive, etc.
Also note: the only reason I know that you manage content from various sources is that someone mentioned an intro video and I managed to find it by going to the footer of the page and clicking on tutorials.
It's great feedback, definitely more food for thought. Thank you! It's a fine line between cutting features vs. trying to solve too many things at once.
Our current approach to the collaboration part can be seen when you link a Google Drive account. When you want to edit a Google Doc it takes you right there, no need for the GDrive UI. You can actually create a Google Doc from within Shelf.
Also, "good" to hear what you wanted to know but didn't learn immediately from the website. We'll surely be working on making the use cases and functionalities more clear.
You're right, Shelf does have some of the Evernote functionality, I guess most notably the web clipper. What we focussed on is more of where Evernote falls short. Which in my opinion is good and easy collaboration across teams.
An advantage of Evernote for now is that Shelf doesn't have offline note-taking. What do you think, is this something hugely important to have?
I definitely like offline note taking, but I don't know if it's a deal-breaker. I agree that Evernote's collaboration is weak (which is fine, Evernote's focus is personal notes - and I think it makes sense to have a note app that is team focused).
Then there is the issue of linking the Git release/tag with the corresponding changes, say from a ticketing system such as Jira. That can be helpful to communicate changes to other people within the organization and to users.
How do you define dependencies for releasing new versions to service? Likely going to happen at some point when you have non-trivial changes to services.