I am building a XCFramework for my company and the primary purpose is to expose our data for clients using this Framework. Clients can access data using this Framework through use-cases without knowing the implementation details.
This Framework needs a very high run-time maintenance support as we may have to add or update the use-cases based on clients requests or changing busing requirements. It's very important to design an automated solution to deploy new changes and make the updated Framework available for clients. I'm looking to host SDK somewhere so I can build and deploy it. Something like maven for Android. But I've not found some good solution yet.
I would love to hear if someone has similar experience or if someone can guide for a better solution. Thanks
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 10 months ago.
Improve this question
I've never worked at a tech company. I built an app from scratch with a NodeJS API and MongoDB hosted on AWS.
I will start hiring back-end developers to work with me.
What is the best way to making changes to the backend? All the .js files are stored in a repository, but what's the best way to test changes to the API before shipping?
The app is live on the app store. Should I put a duplicate build on TestFlight and connect it to version_2.js files and test it like that?
Or is there a better way to do it? Curious about what industry folks typically do.
There are a number of considerations:
Environments
Many would have multiple “environments”. Frequently, you would have at least “development”, “test”, and “production” environments. Many organizations have a fourth environment, adding a “staging” or “pre-production” environment to that mix, something that mirrors production as closely as possible and is the last test platform before going to production.
For each of those environments, you would then have corresponding builds of your app, one that targets each of those environments. Each of those would be a separate TestFlight target so that testers can download and simultaneously run dev, test, and production builds of the app, which would go against the relevant backend.
Testing
There are a variety of types of tests that you should have. At a minimum, you should be thinking about:
Unit testing
Integration testing
UI testing
The building of these tests should be part of your development methodology. You should be automating these tests, doing regression testing with each new release, reviewing code coverage, etc.
Clearly, there are other types of tests that should be run (e.g., stress/load testing, etc.), but the above should get you going.
Source control
You should have all of your code under source control with branches that correspond to your environments (outlined in first point above), so you know what code is placed in which of the environments.
Project management
You will want a project management system that dictates what is under development. Depending upon your development methodology, this will consist of “stories” that describe the work being done (which should correlate to the commits in your source control).
You will often have a kanban board that correlates to these stories to where they are in the development/testing/deployment process and which environment they are in. This is where developers will indicate that code can be migrated to one of the test environments, where reviewers can either send PR back for further development or advance a PR to acceptance testing, where acceptance testers can indicate whether something is ready for deployment, etc.
Semantic versioning
I'd suggest a semantic versioning system. E.g., you might have the server communicate the API version, so that the client knows whether a newer version of the app is required or recommended.
You might also consider namespacing your endpoints. For example, you might be working on v1 endpoints, but when you introduce some breaking changes, that might be v2 endpoints that will be stood up in parallel (at least temporarily) with v1 endpoints. Etc.
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)
We currently have a .NET SaaS web app with individual deployments per customer. We are on a monthly release schedule and each customer is upgraded to current releases on independent schedules. Sometimes a certain member might even skip an entire release, upgrading on the subsequent release.
We are looking to develop a native iOS application and are trying to figure out the best way to keep a single iOS codebase in sync with multiple supported server-side deployments. I know that Citrix ran into this with GoToMeeting because at one point there were multiple versions of their native app in the App Store to satisfy customers with a variety of server-side versions. Supporting multiple releases corresponding to currently supported server-side deployments in the App Store is not an option we are considering. We have discussed having conditional branches in the code to check which version of the server-side code the customer is using and disabling more current code and features for those users, but this isn't ideal either. Certainly others (such as Citrix) have run into this and have come up with cleaner solutions so I thought I'd cast my net and see what responses I could get. Any help or suggestions greatly appreciated.
Thanks.
When dealing with differences in API versions I would think a configuration file on your iOS app is essential. By configuration file I mean a plist or just settings download that fires when the app runs and tells it where to go for api's. This lets you do what you need with other api versions and when you are ready you can just change the configuration and point it at new versions.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm looking for a consensus for one or the other
Beta; Release software that is semi-
functional to a limited audience and let users guide the
process until an application is
complete.
No Beta; Define all functionality
based on previous user-feedback
and/or business logic, build the
software, and test it with whatever
time you give yourself (or are given).
Hmmm...Beta is for a product you think is finished...until you give the Beta users to play with it and they break it in ways you haven't thought of.
So, yes, go with Beta, unless you want to burn your product on many users.
I disagree with both of your cases.
How about internal QA? They find bugs too, you know. Only release a beta to customers when you have no known serious bugs.
Also, always test adequately. If time is pressing and you haven't finished all your tests, then that's just tough. Finish testing, whether you have time or not.
My answer is that there are many factors that would determine which makes more sense:
1) Consequences of bugs - If bugs would result in people dying, then I think a beta would be a bad idea. Could you imagine running beta software on a nuclear reactor or on a missile system? On the other hand, if the consequence is fairly minor like if there is a temporary outage on some fantasy sports site, that may not be so bad to put out in beta.
2) Expectations of users. Think about the users of the application and how would they feel about using something that is a "beta"? If this would make them scared to actually use the software and be afraid that it is going to blow up on them regularly and be riddled with bugs, that may also play a role.
3) Size of the application. If you are going to build something very large like say an ERP to handle the legal requirements of 101 countries and contain hundreds of add on modules, then a beta may be more sound than trying to get it all done and never get to where you have customers.
4) Deployment. If you are setting up something where the code is run on your own machines and can easily be upgraded and patched, then a beta may be better than trying to get it all done right in the beginning.
5) Development methodology. If you take a waterfall approach, then no beta is likely a better option, while in an agile scenario a beta makes much more sense. The reason for the latter is that in the agile case there will be multiple releases that will improve the product over time.
Just a few things I'd keep in mind as there are some cases where I easily imagine using betas and in other cases I'd avoid betas as much as possible.
Undoubtedly beta!
Some benefits of running a beta period ...
Improve product quality, usability, and performance
Uncover bugs
Gain insight into how customers use your product
Gauge response to new features
Collect new feature requests
Estimate product support requirements
Identify customers
Earn customer testimonials
Prepare for final release
Generate buzz for product release
Launch quickly and iterate often.
Without knowing what the app is and what it's audience will be, I think that would be a hard choice to make. However if it's an Open Source project, it seems like the consensus is usually "Release Early and Release Often".
The real question is this: Do you know exactly what your users what?
If you answer yes, then design and build everything and launch it with no Beta.
If you answer no, then Beta is the way to go - your users will help define your software and they will feel more a part of the process and have some ownership.
I say Beta. But I disagree with your premise. You should never release semi-anything software. The software released as Beta should at least be feature complete. This way your users know what they're getting into.
As far as finding bugs. Internal testing is best. However, anyone that has released software knows that no matter what the user will find a new and interesting way to break it.
So Beta 'til your hearts content.
I would suggest alpha testing first, to a select group, that is not feature complete, so they can help you find bugs and determine which features are needed.
Once you get what is thought to be feature complete, then release it to a larger group, mainly to find bugs, and to get comments on feature changes, but you may not make feature changes unless there is something critical.
At this point you are ready for release, and you go back to step (1) for the next release.
After finishing (you think) your software, and believe that there are no serious bugs, conduct alpha testing. Make the software available within the test staffs of your company, fix the bugs reported.
Next, release the software to customers as beta testing, collect comments, fix bugs & improve features.
Only then you're ready for release.
Neither.
You shouldn't release a beta until you feel that the product is bug-free. And at that point, the beta users will find bugs. They will, trust me. As far as letting the beta users 'guide the design', probably not a good idea - you'll end up with software that'll look like the car that Homer Simpson designed. There's a reason why beta users aren't software designers.
As far as the second option - unless you are an extraordinary tester, you will not be able to test it as well as end-users (they will do the silliest things to your software). And if you "test it with whatever time you give yourself (or are given)", you will not have enough time.