I don't understand what does codemagic team mean on this screenshot. Why should I add 100 to build number? Or this is just an example? And when should I update 1.0.0 to 1.0.1 or 1.1.0 to 1.2.0?
It's just an example demonstration how to add greater numbers. Often necessary when you have already built many times locally and are switching to automatic - otherwise your publishing will fail. If you do not have any releases yet, then just using $BUILD_NUMBER is sufficient.
I think updating the build version is up to the developer though - and there are no strict rules how to do it - just move upwards with it.
https://rollout.io/blog/best-practices-when-versioning-a-release/
Related
How to avoid microservice dependency without slowing down your release process
We are deploying services and its a microservice based project but since we are having many small services going through parallel development we are struggling for deployment.
Example -
Admin build - v1.1.1
this is having dependancy on some other build v.x.x.x
so once build x is not fully tested we can not release admin v1.1.1
is there any solution for it to make deployment process more smooth ?
2 Pointers I can give you are:
Always have your API's backwards compatible - this way you lower your dependencies in one version or the other, creating higher isolation.
Use feature flags - when you change behaviour you can then deploy the code but it doesn't have to be active at that exact time. Use feature flags to wrap your changes and switch them on when you are ready.
I'm developing an Eclipse plugin and i've run into this problem several times already.
I always keep my Target Platform updated for the latest (stable) Eclipse release so that i test my code against all the recent updates, fixes etc.
However, this may (and have) result in accidental breakage of backward compatibility of my plugin, e.g. when i accidentally use new API that did not exist in the Eclipse version i aim to support.
Or, more sneaky example, in 4.6 Eclipse moved to Java 8 and some interface methods got default implementations. Now when i implement these interfaces my IDE doesn't automatically generate empty implementations for those methods and no error is generated. If i install and run this code against a previous Eclipse version these methods will throw AbstractMethodError since no implementation has been provided.
So my question is: is there a tool to further restrict API my Target Platform provides to some earlier Eclipse API version?
Is API Baseline an appropriate tool for this? Because i couldn't get it to work like this. (It allowed even non-baseline method calls not to mention the more complex default-methods example.)
You can use multiple target platforms, switching between them doesn't take long. For testing Stack Overflow questions I have one Eclipse install with 10 target platforms.
So have a target platform for the oldest release you want to support as well as your current release target platform and check the code runs against that.
It is particularly important to test with the actual Target Platform if you want to support Eclipse 3 releases as the were large changes going from Eclipse 3 to 4.
I've been trying to include Fastlane in a CI environment where the following should happen:
any commit to the master branch should trigger a test run and then a build into Testflight.
any commit to the development branch should trigger a test run and then a build into Fabric Beta.
any other commit or pull request should trigger a test run.
The lanes are working with all the code signing through match.
In order to avoid building twice I'm building through Gym and then Scan with skip_build: true and clean: false, as mentioned in #3353.
Although this does seem to help with the build time, due to the amount of cocoapods dependencies, it goes over the 50 minute limit in travis-ci.org. (Feel free to check the build logs)
How can this be improved in terms of running time? (Aside from fixing the slow compiling Swift functions mentioned in #3)
For reference, here's my Fastfile.
One way you can speed up your build phase is using prebuilt frameworks. It's like importing AVFoundation or any other Apple toolkit on your project.
Try to identify which dependency is slowing the running time down and move it to a prebuilt framework.
Carthage is a nice tool that allows you to use prebuilt frameworks and manage dependencies as well. You can cache Carthage builds on your CI. Check out this great blog post on how you can achieve caching.
I don't know of a way to re-use pre-built derived data for scan, gym and snapshot. Main reason for that is that those are builds for different architectures, with potentially different xcconfigs.
I have a specific problem but the solutions are hopefully probably generic for similar problems.
I have a Play! framework 2.0 project, using Scala.
I am trying to deploy a new version to Heroku.
However for this project the deployment fails as the slug size is too big (101MB).
Now this app is very simple, so it is most likely a configuration problem. The current deployed version is/was using Play! 2.0-RC3 and the one I am trying to deploy is using version 2.0. That may be an issue?
I have tried to use a .slugignore file, ignoring .ivy2, project/boot etc, but to no avail.
Any other suggestions for how to reduce the slug size? When Using Play 2.x and Scala?
Here is the git push output (excluding the Selenium dependencies is probably a start)
Just follow the instructions on the bottom of this page. You simply fork https://github.com/heroku/heroku-buildpack-scala and change the bin/compile script towards its end as described in the Finetunig section.
EDIT: as of the time of this post the code was in the buildpack repository but not yet live, as per #JamesWard comments. I assume it will be released soon :)
I see that your application was started a few months ago. Try to remove the Heroku application and create it again from scratch.
Heroku's buildpack already contains the changes listed by Fynn to reduce slug size (tested yesterday), but if your aplication is old it may be that the changes were not added. Of course, you could modify your buildpack, but it may be simpler to just recreate the app.
I have been playing around with the new StateMachine workflow that has been added to Windows Workflow as part of Platform Update 1 (see also). I now want to look at installing what I've created and therefore need to make sure my bootstrapper is up-to-date. In the future, I will be moving to WIX but right now, for the purposes of prototyping, I'm just using a regular Setup and Deployment project and its bootstrap support.
The list of standard pre-requisites does not include the PU1 as an option. Therefore, how can I add support for it?
Update
I found this answer on StackOverflow regarding custom prerequisites, which led me to this article on MSDN, which led me to creating my own pre-requisite. However, I got a new error about mismatched framework requirements. I suspect I need to pick apart the multi-targeting support and the existing .NET framework prerequisite package to see how to make a new prerequisite that will work correctly.
I've had a stab at creating my own bootstrapper packages for this. The results are here to download. Note that these are entirely untested and provided as-is - use at your own risk. However, feedback is welcome. Hopefully Microsoft will provide an official solution.
See How to detect if the .NET Framework Platform Update 1 is installed
is the Microsoft .NET Framework 4 Platform Update 1 - Runtime Update (KB2478063) what you are looking for? See here for the download.