I'm partway through development of a build wallboard that displays the last 20 automated builds undertaken by the build server, all looks well and good, and when a build has tests, i'm automatically recording the test results (to be used interactively later)
I love building instant messaging bots and since my new workplace uses Lync (2010) I have started building a bot interface, that works over that.
I have managed to get it to start a conversation with the people that requested the build, that's about as far as i've got so far - i'm hoping to allow the users to ask 'why?' and be responded to with build errors or which tests failed etc etc. Thanks for reading through the backstory!
The Question
Should I continue writing a bot on lync? It seems like a pretty cool platform and protocol, but it seems very proprietory, and locked in. Are there more open platforms I should aim for that may end up being supported by Microsoft's unified messaging doodah with lync2013.
Thank you for your time, I hope this question is specific enough.
If your organization has already invested in Lync and its infrastructure, it's hard to imagine them giving up on it unless it has major issues.
Of course there are other options, but it's not like Lync is going away anytime soon, and Lync 2013 recently came out so it is still being invested in by Microsoft. And there is a wealth of information/documentation/communitry (i.e. TechNet) around the Lync SDKs, so that is also a bonus.
Also, Lync is built on top of SIP and well-known media codecs, which are not proprietary. (their SDK is proprietary, of course)
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
Apple today bought out Buddy Build and announced there will be no more support for Android. What is a good alternative for Buddy Build?
List of Mobile App - Cloud Build Solutions
List Criteria/Details:
This is NOT an analysis nor endorsement of any of these solutions.
I tried to list ONLY solutions that support both Android and iOS at least. Buddybuild did support some hybrid frameworks, but it was not their focus.
I focused on MOBILE projects since that's Buddybuild's focus. There are plenty of solutions (not listed here) that are for web, docker, etc.
I focused on CLOUD HOSTED solutions only since that's also what Buddybuild was. There are several solutions (not included here) if you're willing to host your own build server.
This list is limited to solutions that BUILD in the cloud. In other words, solutions where you have to do your own build and then you deploy it to the cloud are not included.
With that out of the way, here is a list of what I've found so far, in no particular order - and with very little analysis other than a quick read of their websites. Corrections welcome, but please be kind about it because this is a quick list!
Nevercode - https://nevercode.io
CircleCI - https://circleci.com
Travis CI - https://travis-ci.org
Bitrise - https://www.bitrise.io
Buildkite - https://buildkite.com
AppCenter - https://appcenter.ms (yes, this is Microsoft and they do indeed support iOS, Android and more.)
Buildozer - https://buildozer.io
The is also a healthy discussion going on at https://github.com/rnystrom/GitHawk/issues/1330
The above is "the answer" to this question but In case some folks are not fully aware of the context, read on for some background on Buddybuild.
What is Buddybuild?
Buddybuild is a cloud-hosted continuous integration platform to build, test and deploy iOS and Android Apps with ease. Their claim to fame is the ease with which one could setup a build. Having been a customer for several years, I can attest for this.
A typical Buddybuild workflow includes an iOS or Android project where the source code is hosted on GitHub, Bitbucket and others. From there, the Buddybuild systems monitor commits to the source code and, based on a project's configuration, produces builds that can be sent to end-users via email (presumably beta testers, business testers, etc) and that end-users can install very easily from just the email.
In addition, for iOS projects, Buddybuild is also able to manage Apple Provisioning Profiles and even manage the Team Device list. This is an area of iOS development that is often time consuming for teams as Apple requires all devices running a test-build of an App to be "registered" in the Apple Developer Portal. Buddybuild can manage device provisioning seamlessly and, to my knowledge, is the only product that offers this feature (but I could be wrong).
Buddybuild also offers an optional SDK for both Android and iOS that provides extra features to Apps that use it. Namely, the SDK allows developers to collect feedback from their users as well as crash report data that is correlated back to source code. The feedback feature is particularly powerful as it required no code by the developer at all while still providing a visually appealing interface to collect app feedback from users (complete with a screen grab of whatever the end user was seeing at the time of feedback.)
Why the fuss?
Buddybuild announced on 1/2/18 that they've "joined the Xcode engineering group at Apple to build amazing developer tools for the entire iOS community". See Buddybuild's blog post about this. Their announcement also stated they've stopped accepting new customers (even for iOS) and that they're ending Android support 3/1/18.
Disclaimers:
I am not affiliated with any of these solutions.
I have used CircleCI before, but for a NodeJS project so I have zero experience using CircleCI for iOS and Android.
I am a Buddybuild customer and maintained 10+ apps for both iOS and Android using their platform.
I am not affiliated with Buddybuild, but I have given several talks on using Buddybuild. I know several people there and I honestly believe in Buddybuild's solution, workflow and UX. I am a super-fan, but have no special access nor knowledge beyond what is public.
So the answer to my question is AppCenter - https://appcenter.ms.
Don't waste your time with the others. Every once in a while Microsoft writes decent software. It's not buddybuild but it's the next best thing. The other ones made me want to tear my hair out. If you have to talk to customer support all the time to get things to work - that's a bad thing. With AppCenter I was up and running in 10 minutes. Easy, stupid-proof configuration - no room for errors of any sort.
Microsoft is pouring a ton of resources into App Center - it's only been launched since August of 2017. They have 24 hour support and they are going to start working on automated signing for iOS in the coming months.
If you really need a lot of flexibility and integrations go with BitRise - but be aware that you'll be spending a lot of time getting things to work and things will break constantly. If you have a dedicated DevOps person on your team and you love customizing/programming your workflows with bash scripts then BitRise may be suitable for you.
I would like to start off by saying that I am a novice programmer. I have only learned Java and Android studio, and I know very little about cmd prompts and that sort of thing. I recently found j2objc which can roughly translate my java code to objective c, and hopefully make it easier for me to transfer my app to ios. I also know there is a gradle version. For some reason, there is no "tutorial" on youtube about setting up any type of j2objc. My Android studio project is on my Windows 8 desktop and my IOS xcode app is on a VM running IOS 10.13. Can anyone help me get this working? (I may need you to explain things to me like I'm 5).
I'm sorry, but as the project lead for j2objc, I don't recommend you use it. j2objc has more benefit as the amount of shared client-side grows, so smaller apps go through a lot of pain for very little benefit. Our most successful client apps tend to be huge (think Gmail, or the Google Docs apps), written by large teams of engineers.
What I encourage is that you initially focus on sharing code on the server-side, with your apps providing the user interface but doing very little calculation on the client. If profiling your app shows it is slow due to network accesses, then you might consider caching or some other local code. If you keep all the interesting/changing features on the server-side, then small, lightweight clients require much less work even if they are rewritten for each new platform your team supports.
Clarification/summary for the question -- we're looking for:
a hosted bug tracking system,
that is as convenient to use as lighthouse/github/launchpad,
can deal with attachments,
integrates email notifications and operations (implies operations in commit messages),
has a script-friendly API,
allows anonymous bug reports, or ones with an email but that do not require setting up an account for submission.
Lighthouse is close but fails on the last point, launchpad is similar, github also doesn't handle attachments. Tender is great for the last point, but fails as a general bug tracking system (and it looks like its open-source version will be limited to basically being a forum).
We looked into a number of applications to install and setup -- but with this range of requirements, they are always coming with a huge cost in terms of investing time in setting up and maintaining a working system.
In our (open-source) project we have been using Gnats for a really long time. It doing what it was designed to do fine, but that's getting to be pretty inconvenient: it's no longer maintained, has features that we never use, and lack features that we'd want to use... It doesn't deal with attachments, has no easy way to perform actions via emails, no integration with commit messages, and a web interface that was designed for 90s browsers. So I've been looking around in an attempt to find something that could replace it, hopefully some hosted solution to avoid the setup/maintenance hassle.
Probably the most impressive tool that I've seen is lighthouse: it has a very nice and practical interface, properly deals with attachments, controllable via emails, and can respond to commands in commit messages. But... It doesn't have any sane way to submit a bug anonymously -- and that's a major requirement, since we need any random user to be able to submit bugs through our IDE. (It seems that there is a possible hack to forward an email faking the From field, but that doesn't work very well -- specifically, the reporter should be included in the followup email exchange.) On the other side, there is the related tender tool, which is very good in that area, but is very basic otherwise -- too basic to serve as a bug tracking system.
There's a whole bunch of other sites that I've tried -- it seems that all of them require submitters to have an account, so they don't work well for our needs; as well as being limited in various other ways (don't deal with attachments, no good email integration, etc etc). It doesn't help that the meta-descriptions of these sites is usually pretty obscure: it took me hours to just figure out what tender/lighthouse are and how they're related, and no site mentions its inability to receive bug reports without registration. (I'm looking only at open-source-friendly sites, since we don't have any kind of budget for such things.)
There's also the option of installing some system locally, but bug tracking systems tend to be monsters that I'd like to avoid configuring and maintaining, if possible.
So the question is: is there anything obvious that I'm missing? Or to make it more concrete: is there a good comparison page somewhere that lays out popular options and their respective features explicitly?
JIRA is free for open source projects. It's far more user friendly than trac and bugzilla, and allows anonymous submissions and plugins. Unfortunately you'll need to host it on your own server, but from personal experience I can tell you that all you need to do is install a database (it can run without; but that's not a good idea) and it basically maintains itself.
Also is there a particular reason why Google Code or Sourceforge issue tracking tools wouldn't work? You don't need to use all their services if you don't want, you could use them purely for issue tracking.
Did you try trac? It is used by many open source projects.
FogBugz is one option. They'll host or you can run it yourself. My company looked at it but ... political considerations ... meant it is not viable here.
Have you looked at this Comparison of issue tracking systems on Wikipedia?
I have also found fixx, by hedgehoglab. Apparently it has the features that you care more:
Get things done
fixx has an intuitive interface to enable quick bug
reporting. Filling in a bug report is
as easy as sending e-mail.
Ability to add multiple attachments to issues allowing you
to attach screenshots and manage
documents related to issues.
Clever notification options to keep relevant people informed while
preventing issue tracker spam.
Also:
It has an open REST API.
I see that you are using Subversion as SCM. There is a Subversion integration with fixx.
Its unique installation requirement is Sun JDK 1.5.0.
It seems free for Open Source Projects and an hosted version is "Coming soon".
Note that I have never used it, so I cannot give any recommendation.
The open source BugTracker.NET has support for the following areas that are giving you problems:
Attachments
Guest login
Email notifications
SVN commit integration
I found it easy to set up, maintain, and tweak. Of course, you might think otherwise if you are not familiar with .NET and have a Windows server available.
You might look at Unfuddle. They do allow an API for the submission of tickets and have your other points covered including attachments.
Take a look at repositoryhosting.com They have ready made solution with trac / svn / git, for you. Comes with all kinds of bells and whitsles, such as Agilo plug-in and auotomatic backup to the amazon S3 bucket of your choice.
The prices are very reasonable.
Also, jumboxes offers a Trac / SVN virtual appliance that you can host in your own environment.
Redmine is a good open source option. You can check an online demo and a list of features.
It's not hosted though. But it's an interesting option.
And you can always check a list of different open source bug tracking alternatives
I've used ZenDesk in the past and it was rather hassle free.
In addition it has an api: http://www.zendesk.com/api.
Moreover I KNOW it can CC whosoever you want it to whenever anything happens.
We too are looking for a new solution.
At present we're using FogBugz, which is painfully slow.
We need our customers to be able to log bugs via email. Tender looks perfect, with the exception that it doesn't have any obviously usable ID fields that we can pass around. Is there a plugin or similar? I could knock up a browser extension to "goto bug id [whatever]" but that seems kludgy for what should surely be a core feature?
I am currently creating a business case for rolling out TFS 2010 as our source control and bug/release management tool.
We currently use OnTime for our bug tracking software and subversion for our SCM.
I was wondering what advantages TFS 2010 has over OnTime?
I have done some thinking so far and would love to hear responses:
TFS 2010 allows linking changesets->work items->builds
TFS 2010 provides greater customisation of workflow than OnTime
TFS 2010 is integrated into the Visual Studio IDE - This requires less apps to be open and less window flicking
Thanks in advance.
TFS is one of the least intuitive Version Control systems I have ever had the misfortune to have to use. It may have numerous "bullet point" advantages over OnTime (and other comparable systems), in terms of raw feature-lists and capabilities, but the key factor is whether it can fit in with your working processes.
My experience with TFS is that you will be required to adapt to the TFS way of working, because adapting TFS to your way of working will be impossible or too difficult to justify.
We recently reviewed a number of possible alternatives to replace a system comprising SVN and a manual bug-tracking system (Excel spreadsheets). On-Time was evaluated but deemed too expensive and complex.
In the end we opted to continue using SVN, but drastically revised (simplified) our repository structures and chose to combine SVN with the FogBugz issue tracking system. The integration between these two systems was fairly rudimentary "out-of-the-box", but required only a little effort on our part to achieve the much closer level of integration we desired. Certainly far LESS effort than my previous experience of a TFS roll-out involved.
Our SVN/FogBugz system is also now integrated with a FinalBuilder build automation suite.
The result is a system that not only fits our working practices perfectly (since we devised the means by which the systems would integrate to achieve that) but which is also infinitely adaptable as our working practices evolve.
I think that it really depends on the size of your team(s), and what you want out of source control.
I used bugzilla in combination with Perforce for a couple of years and found that both were really very good at their own individual things while working in a very small team (2-3 people), but the suffered from a lack of integration between them and from some little idiosyncrasies that took time to get used to.
I recently moved to a new job where TFS is used extensively. There are 4 main teams in this company with 10-12 developers in each, split into further project teams below that level, and it is in this kind of environment that TFS really shines imo. It's biggest advantages in my view are:
1) The integration with Visual Studio - it's not just a case of having less windows open, but it really does speed things up and make your life easier. Things like VS automatically checking out files for you as you work (no issues with accidental checkouts due to lockless editing), being able to synronise local + TFs builds, being able to quickly compare the local version against previous ones..yes you can get 3rd party plugins to integrate but none to this level and with the same stability.
2) The communication features - simple things like integraton with Live Messenger (provided you configure TFS correctly) are great for large teams. We use WLM to communicate accross the office and for collaboration as its just quicker than walking over to someone else every time you need to ask a quick question.
3) Linking builds/changelists to tasks - Yes other SCMs do this but again it's just done in a very nice, integrated fashion..I guess it's nothing special to TFS but personally I like how it tracks this.
4) Ease of merging/lockless editing. I've had experience with some other merge tools and the TFS one works nicely enough, making merging after concurrent editing pretty simple. It's very similar to perforce in this respect, but also with a usually pretty effective auto-merge tool which I use for tiny edits that I know cannot cause any potential issues with edits other developers are working on.
5) Auto building/build management. Working with a couple of large solutions containing 20-30 projects that depend on each other, this is a godsend. We have it set to queue up a build every 20 minutes IF something has changed, and when one has happened its listed in the history log..so easy to see when you need to update your local libraries.
I don't have any experience with configuring it other than build management, but I have heard that this is the worst part of TFS..that its a bit of a pain to get everything running correctly.
So, translating that to a business case..I'd say that if you are a Microsoft software house with large/multiple teams, then the time savings and productivity improvements that you will see as a result of the above features are worth the investment in setting it up. Its free to use in most cases as you will probably have a MSDN subscription (maybe some CAL issues but i'm not sure) so your biggest cost will be in user training and configuration.
Firstly, I would suggest to consider what is your primary concern, what is the problem that you are tying to solve by rolling out TFS.
In terms of version control I would recommend the blog post from Martin Fowler on Version Control Tools and a follow up results of a version control systems survey. Admittedly this might be and is a subjective view of the subject but one that seems to be pretty popular. TFS clearly looses in comparison to other Version Control Systems.
I currently work with TFS2008 and we have migrated from SourceSafe and IBM ClearCase/ClearQuest and there is no doubt that TFS is far better then any of the previous tool, still it has its serious shortcomings and the new version will only partially address those.
Addressing the individual point you have raised:
TFS allows to link builds with changesets and work items, but so many other systems
I have not used OnTime but the workflow customisation can be both an advantage and a hindrance. Potentially, there might be a lot of work involved in creating a custom process template and you would still need a sensible UI on top of it (Team Explorer or Web Access might not be sufficient)
Integration with Visual Studio is an advantage but there are add-ons to Visual Studio that allow integration with other source control providers
On the advantages of TFS I would probably mention
Distributed builds and separate build agents - if you do many builds
Full integration with Visual Studio via the Team Explorer
Extensive reporting infrastructure (though you can only take full advantage of it when using MSTest for all the testing)
SharePoint collaboration site for each project
Given the substantial cost of rolling out full TFS installation I would really consider what real business benefit would this solution give you that others don't.
Not shure about TFS, but the UI of OnTime is kind of non intuitive.
Also I dont like that you have different fields for Bugs and Tasks. Of course you can always add your own fields, but the default layout should be ready to use.
We endet up using only "Bugs" even if it is a task.
I dont say its a bad product, but if TFS has a better UI for bugtracking now (which it hadnt 4years ago when I had to use it and hated it ), then this would be an argument for TFS.
Sorry to hear that you want to get rid of SVN. Thats a hard decision.
I'm not sure about the licensing for the Axios OnTime but if you have an MSDN subscription then it's no additional cost. See the blog post here
I've been using TFS 2008 only for version control and while it's a nice upgrade from VSS some things that we're tyring to do aren't exactly in line with what is expected. That said, I've written a quick little web app that fills in those gaps. It was pretty easy to develop against using the API and there's lots of addons to help with specific tasks.
Probably not the answer you want to hear, but I'd be doing my damnedest to make a business case against TFS.
In any event, my general advice would be to try it out yourself (or in a small team) on some very small, but real project - maybe some tool you need on a once-off basis, code that can be thrown away or easily migrated to another system because it's small. There's nothing like actually using the system!
I have used OnTime and Subversion. I have not used TFS as bug tracker, but I've used it for source control. The source control part of it is basically still the bad old Visual SourceSafe. If you are currently using Subversion you will be swearing your head off any time you need to rename a file or, heaven forbid, delete a file and then create one with the same name - never mind any branching or merging. It's hard to convey in a post just how primitive and fragile it is as a source control system - that's why you really have to use it. You'll see what I mean when you find yourself stuck with a file you can neither check in nor delete and some meaningless error. Not that Subversion is perfect - but it's a decade ahead of VSS!
The workflow part of TFS, which I've only briefly played with, seems very "heavy" to me. That is, it really restricts the user to that workflow and requires a lot of steps that are often unnecessary. This stuff can help, but it can also just as easily get in the way. A good system provides the workflow when it's needed, but allows you to bypass it when it would just get in the way. When we used OnTime, we found that even its relatively unobtrusive workflow was often just more trouble than it was worth. Of course, this all depends on the specifics of your situation. How are you using OnTime workflows now and what do you want out of TFS that OnTime doesn't provide?
Linking changesets to bugs can be done with Subversion as well. It supports some extensibility mechanism - I don't remember the details, but FogBugz uses it (we switched to it after OnTime). Linking the to builds can be done by adding a simple svn tag command to your build script. Visual Studio integration can be done with VisualSVN.
The cost is also a huge downside of TFS. It is very expensive for what it does, especially when you take into account how well it does it. Yes, it's "free" if you have to have an MSDN subscription for every developer anyway - but do you have to, without TFS? Subversion is free, full stop. OnTime and FogBugz are far more reasonably priced.
I would strongly recommend against TFS. I once tried to restore the source code from a crashed instance, but I gave up after a few days, so source code was lost (= it failed to do the one thing a VCS should do). Of course, I might have done something wrong, but it's not easy to get everything right when the restore guide is two miles long, and it really is something that should happen so rarely that nobody is experienced with it.
Now I use Subversion/Trac, which gets the job done (and customizing the workflow in Trac is so easy it's not fun, compared to TFS).
For the time being, avoid TFS!
I would stick with SVN + FinalBuilder and then choose between FogBugz or CounterSoft Gemini.
My company are imposing Jira and Zephyr on us for defect tracking and test management. We're quite happily using TFS 2008 for both these jobs at the moment, but management have never let the fact that something isn't broken stop them from trying to fix it.
Are there any tools/plug-ins that will allow us to synchronise between the remotely hosted repositories and our in-house TFS server?
Probably too late, but the company might want to look at the new features for bug tracking and manual tests coming in the 2010 release. Nice as Jira is, I doubt it will integrate well with the historical debugger and the ability to include a video of the test, as well as information on the test environment, and have it all be part of the work item.