Question for the Hive mind....
-
Hi All, My current employer (for how long but that another issue!) is trying to move to having all 'stuff' online (well lets give them some credit!) GIT was used to track some files (not source code!) and now are we use Sharepoint, first thing is this right, I was fairly certain we shouldn't use GIT but is Sharepoint the right thing to use? :confused: Glenn
I've been told the SharePoint does some rather cools things, but I've never seen them, because, from my experience, 99.9% of places just use it was a fairly lame wiki. Using Git to store files that aren't versioned text files, would seem pointless and counterproductive. A DropBox/OneDrive/GoogleDrive would seem better.
Truth, James
-
I've been told the SharePoint does some rather cools things, but I've never seen them, because, from my experience, 99.9% of places just use it was a fairly lame wiki. Using Git to store files that aren't versioned text files, would seem pointless and counterproductive. A DropBox/OneDrive/GoogleDrive would seem better.
Truth, James
The use of GIT caused people to ask 'why!' to which I had to give the lamest answer: 'I'm only obeying orders' GoogleDrive was rejected as not secure enough, OneDrive as too secure and to easy to delete & Dropbox was not as far as I am aware discussed. It's just with 365 Sharepoint is being used to store everything! I did as as 'it might be good if these thing' (images, png's which were derived from some PDF Documentation) 'could be stored in a directory' to which the reply was 'Meh!' using teams has not improved people skills.
-
Hi All, My current employer (for how long but that another issue!) is trying to move to having all 'stuff' online (well lets give them some credit!) GIT was used to track some files (not source code!) and now are we use Sharepoint, first thing is this right, I was fairly certain we shouldn't use GIT but is Sharepoint the right thing to use? :confused: Glenn
late to the party, but ... I was asked the same sort of question on my last contract - It would have been nice to be able to suggest Sharepoint - but the company wernt anywhere near where they needed to be skills-wise given we were just beginning to get them set up on O365 The top two thoughts I had, and I stipulate this very carefully, 'based on their requirements', were GIT, with GIT LFS and SparkleShare Umbraco CMS (or similar) Since they had a lot of Azure going on, if I could have found a 'file manager' view suitable for management to use, over Azure File Storage, that would also have been a hot contender (I'm sure there are such products around, but being a start up $$ come into play)
-
Hi All, My current employer (for how long but that another issue!) is trying to move to having all 'stuff' online (well lets give them some credit!) GIT was used to track some files (not source code!) and now are we use Sharepoint, first thing is this right, I was fairly certain we shouldn't use GIT but is Sharepoint the right thing to use? :confused: Glenn
Ah welcome to the MS family, with 365, SQL Server, VS, Teams and now sharepoint your organisation is truly part of the clan. Not a bad thing but you are now susceptible to all the different servers that they can foist on you. Once you get past the tipping point (and that was probably 365) there is n going back. When the sales person says they all integrate and work together laugh in his face.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
Hi All, My current employer (for how long but that another issue!) is trying to move to having all 'stuff' online (well lets give them some credit!) GIT was used to track some files (not source code!) and now are we use Sharepoint, first thing is this right, I was fairly certain we shouldn't use GIT but is Sharepoint the right thing to use? :confused: Glenn
Glenn, First, good luck on your presumed job search. It might depend. I'm not a fan of Sharepoint in the least, but I could see where it might be useful for storing documentation. More specifically, general docs like process documentation (here's how we branch & merge), HR docs, etc. If by 'stuff', you mean 'technical stuff' like source code, then, no, that doesn't seem like a very good solution. Even project docs like requirements and design (to me) need to go in a change control system like jira or whatever. Look at me, advocating using jira/whatever when (as my current employer already knows), email is a perfectly valid change control system.
-
Glenn, First, good luck on your presumed job search. It might depend. I'm not a fan of Sharepoint in the least, but I could see where it might be useful for storing documentation. More specifically, general docs like process documentation (here's how we branch & merge), HR docs, etc. If by 'stuff', you mean 'technical stuff' like source code, then, no, that doesn't seem like a very good solution. Even project docs like requirements and design (to me) need to go in a change control system like jira or whatever. Look at me, advocating using jira/whatever when (as my current employer already knows), email is a perfectly valid change control system.
Thanks not easy at this time, get some agents phoning me to find out if I have any roles available (?), buy 'Stuff' I meant AVI video files, configuration data, docs & diagrams of how to connect widget A to Widget B with letting the magic smoke loose! The test are being converted by myself and another to JIRA via Zephyr (or whatever!) the Chief is a big 'Jira Ninija' and got upset by people trying to use Jira like a relational Database...:~
-
Hi All, My current employer (for how long but that another issue!) is trying to move to having all 'stuff' online (well lets give them some credit!) GIT was used to track some files (not source code!) and now are we use Sharepoint, first thing is this right, I was fairly certain we shouldn't use GIT but is Sharepoint the right thing to use? :confused: Glenn
Also late to the party...long-winded too :) And, good luck on your job search! TL;DR - The single act of purchasing new tool is not going to solve an organization's problems. One must set up conventions and workflows for the tool to optimize team collaboration for the organization. I have found in my "travels" that there is a misconception typically at the decision-making-level in organizations, that these types of tools (GIT, SVN, VisualSourceSafe, Sharepoint/Confluence, JIRA, Wikis, and bunches of others) and the features they provide, once purchased, make all your problems go away without any additional work. The flawed assumption is that the tool forces a specific workflow and thus forces team members to use the tool in just one way and by doing so, creates a single organizational structure for the data to be stored, which we all know is not correct - instead of the desired/assumed "file cabinet" for data (project docs, source, etc.), these tools become "junk drawers" (often referred to as the "wild west") where teams don't know what data is where, what is the latest version, identical doc's are stored in different locations/folders causing data coherency issues, nobody knows what is in the master/trunk branch (or tags or any of the other branches) - and it gets worse and worse as time goes by. The key to team success is, once the tool is purchased, one or a few people build up a moderate level of expertise so they know best how to use the tool then create (and document) a structure (branch definition for source tools, folder structure for doc tools) and workflow that works best for all the organization's requirements, then get buy-in/agreement, and put in the constructs (like varying access rights per group) prior to its use, and police it's use (which can be time-consuming) during its use. Mind you, for those that do contracting, you are often forced into the customer's source control/configuration mgt structure - sometimes a good thing, sometimes not. In agreement with others on the post, using a source control tool like git/GitLAB/BitBucket/Subversion for documentation control is not a good idea - Subversion/Confluence tools are more appropriate. I find source control tools deal best with text-based files (like code), but not well with binaries (like MS docs, etc.) wrt version control. Since I work for a small company, we have shied away from those complete solutions from Atlassian that are costly (JIRA/Confluence/BitBucket). We do use Atlassian JIRA for tasking/bug t
-
Hi All, My current employer (for how long but that another issue!) is trying to move to having all 'stuff' online (well lets give them some credit!) GIT was used to track some files (not source code!) and now are we use Sharepoint, first thing is this right, I was fairly certain we shouldn't use GIT but is Sharepoint the right thing to use? :confused: Glenn
SharePoint or Team Foundation Server?
-
Also late to the party...long-winded too :) And, good luck on your job search! TL;DR - The single act of purchasing new tool is not going to solve an organization's problems. One must set up conventions and workflows for the tool to optimize team collaboration for the organization. I have found in my "travels" that there is a misconception typically at the decision-making-level in organizations, that these types of tools (GIT, SVN, VisualSourceSafe, Sharepoint/Confluence, JIRA, Wikis, and bunches of others) and the features they provide, once purchased, make all your problems go away without any additional work. The flawed assumption is that the tool forces a specific workflow and thus forces team members to use the tool in just one way and by doing so, creates a single organizational structure for the data to be stored, which we all know is not correct - instead of the desired/assumed "file cabinet" for data (project docs, source, etc.), these tools become "junk drawers" (often referred to as the "wild west") where teams don't know what data is where, what is the latest version, identical doc's are stored in different locations/folders causing data coherency issues, nobody knows what is in the master/trunk branch (or tags or any of the other branches) - and it gets worse and worse as time goes by. The key to team success is, once the tool is purchased, one or a few people build up a moderate level of expertise so they know best how to use the tool then create (and document) a structure (branch definition for source tools, folder structure for doc tools) and workflow that works best for all the organization's requirements, then get buy-in/agreement, and put in the constructs (like varying access rights per group) prior to its use, and police it's use (which can be time-consuming) during its use. Mind you, for those that do contracting, you are often forced into the customer's source control/configuration mgt structure - sometimes a good thing, sometimes not. In agreement with others on the post, using a source control tool like git/GitLAB/BitBucket/Subversion for documentation control is not a good idea - Subversion/Confluence tools are more appropriate. I find source control tools deal best with text-based files (like code), but not well with binaries (like MS docs, etc.) wrt version control. Since I work for a small company, we have shied away from those complete solutions from Atlassian that are costly (JIRA/Confluence/BitBucket). We do use Atlassian JIRA for tasking/bug t
Quote:
you are often forced into the customer's source control/configuration mgt structure - sometimes a good thing, sometimes not.
Which how non source code was stored in GIT, because the other version of online storage we could use had no tracibility!
-
SharePoint or Team Foundation Server?
Teams Foundation Server, sounds interesting we use teams to miscommunicate with each other...
-
Hi All, My current employer (for how long but that another issue!) is trying to move to having all 'stuff' online (well lets give them some credit!) GIT was used to track some files (not source code!) and now are we use Sharepoint, first thing is this right, I was fairly certain we shouldn't use GIT but is Sharepoint the right thing to use? :confused: Glenn
Sharepoint is a document management system and would not be very efficient for source\version control. GIT on the other hand is for source\version control of your projects. If your supervisor is trying to use Sharepoint for source\version control and there has been no enhanced additions or modules to support such features than this supervisor is an idiot...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
Teams Foundation Server, sounds interesting we use teams to miscommunicate with each other...
I think they were referring to TFS Team Foundation not Teams, Microsoft's source control offering rather than the chat app, built into Visual Studio, the old VB6 used to have one called Source Safe or something like that.
-
Hi All, My current employer (for how long but that another issue!) is trying to move to having all 'stuff' online (well lets give them some credit!) GIT was used to track some files (not source code!) and now are we use Sharepoint, first thing is this right, I was fairly certain we shouldn't use GIT but is Sharepoint the right thing to use? :confused: Glenn