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 Yocto project that takes quite some time to compile. The final image is meant to run my application and as such, I have a custom recipe in my own layer.
Since building the whole Yocto image takes a couple of ours, I do build an SDK so I can cross-compile my application and transfer the binary to the running device for testing.
Instead of compiling the binary and having to transfer it manually to the device,
can I use the Yocto recipe I've written for my application with the SDK so that I can "call" its do_package()? If other devs could build the .deb (assuming PACKAGE_CLASSES = "package_deb" in local.conf) simply from the SDK that could simplify greatly our workflow.
Thanks!
Huh, bluelightning beat me to the punch. That'll teach me for not hitting refresh. Anyhoo, here's my 2ยข:
Yes, have a look at devtool. The goal of the devtool script is to improve and simplify the development of software for target devices.
First, have your developers install the extensible SDK (eSDK), which is built using this command:
bitbake -c populate_sdk_ext my-image-name
Once you source this SDK, run these commands:
devtool modify my-recipe-name
...make your changes to [sdk]/workspace/source/my-recipe-name...
devtool build my-recipe-name
devtool package my-recipe-name
This should produce a package of your app in [sdk]/tmp/deploy/rpm/[arch]/my-recipe-name, which can then be deployed to the target machine.
Also, have a look at devtool deploy-target if your target machine has network connectivity.
If you give me some more details on your setup I may be able to help more. Hope this at least gets you pointed in the right direction.
This is really what the Extensible SDK is designed to do - provide a pre-built and pre-configured environment and allow you to build applications and other components in pretty much the same way they are built with the full build system. You can even deploy output files over to the target device easily if an ssh server is running on the target.
You can build the extensible SDK with the following command:
bitbake -c populate_sdk_ext <imagename>
For more information you may wish to read the new SDK manual.
I'm trying to build Kubernetes from source using the release.sh script. However I can see that it build client and server binaries for many platforms which are not useful to me. How can I say release.sh to build binaries only for my platform? I can see that KUBE_SERVER_PLATFORMS and KUBE_CLIENT_PLATFORMS checks are done in hack/lib/golang.sh script. But how can I pass those values?
Unless you're looking to cross-compile, or specifically build a release, I'd recommend using hack/build-go.sh, it will pick the host platform for you and just build on that.
I have spent a couple of days going through a lot of sites and reading about Nant , Rake etc.
please forgive my Noob question but I still cannot find what is the difference between Nant and CruiseControl.
As far as I can see Nant can do automated builds , run tests .
so what extra does cruisecontrol do ?
Also there was mention of Teamcity . there too from the documents I can see it can do builds but it also can use Nant but I fail to understand why it needs to use Nant when it can do the builds itself
I am basically trying to follow proper software practices by introducing automated builds at my workplace
Appreciate all help
Nant by itself can do builds and test, but it needs to be launched by some other mechanism such as a windows scheduled job. There is not a capability of launching the build only when source code changes, at least without
an amount of additional scripting.
Nant itself is just a script runner, not a scheduler - it requires some other software (or a manual user action) to launch it.
Continuous integration (CI) tools such as CruiseControl or TeamCity provide monitoring of source control to launch a build process in addition to other things. The build itself could the be a single nant script which runs the build and tests as you suggest, or the build could be done using a series of tasks which are built in to the CI server. The difference is not how the builds are done, but how they are initiated and reported.
CI servers additionally usually provide web-based reporting of the details of the build runs and unit tests.
In summary, Ci tools provide monitoring, scheduling, and reportingin addition to scripting of the build process.
Nant is a scripting language
CruiseControl is a free continuse integration tools
Teamcity in another contiuse integration tools,
regards,
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What tools do you use for Automated Builds / Automated Deployments? Why?
What tools do you recommend?
Hudson for automated builds. I chose it because it was the easiest to setup and demo. A system that's too complex and isn't slick-looking won't impress management enough to get them on-board for automated builds. Especially in a project that has a lot of inertia.
NAnt for builds (but MSBuild, Rake, almost anything would be fine) and CruiseControl.NET for deployments. I'm currently working with the new Cruise from ThoughtWorks studios as it provides a better way to stage the various pipelines and let's me deploy any version I want to a target environment.
We use TeamCity, from JetBrains. They also make Resharper And IntelliJ.
We use it for building our .Net applications, and it has been quite easy to set up, connect to TFS, and run additional tools from. It is very polished, and actually kinda reminds me of this site. Found it much nicer than CruiseControl, and for our team size it is free. If you need lots of different builds, more per-user builds, and so on then it costs a bit (but still quite reasonable).
Funnily enough I just spent two weeks overhauling (read implementing from scratch) our nightly build process. Great fun (no, really). I toyed with the idea of installing Team Foundation Server, but we use Perforce for source control and I didn't think it was worth the hassle.
Our process is now a set of Powershell scripts that run on a dedicated build/test server that do the following on a scheduled task:
Wipe out the entire source tree (check that you didn't have anything checked out first!)
Bring down the entire source tree from Perforce (from the last labelled build)
Generate a change report (by syncing to HEAD and watching what comes down)
Build the App
Index the PDB files to the Perforce sources
Store the binaries and symbols in a dedicated symbol server
Run the test projects
Build the installer
Label
Send out emails to the group with status reports on all of the above
Works well.
make and bash on linux
make and cmd on windows
Visual Build Pro
We use a combination of build tools and continuous integration server:
Build tools:
Maven
SBT
Gradle
Rake
Continuous Integration Servers:
Jenkins
Hudson
Travis CI
Automated Build Studio.
Instead of letting you mes with scripts or xml files, it comes with predefined graphical macro operations that allows you to create tasks easily.
For our Windows-compilable stuff, we use FinalBuilder.
CruiseControl for automated builds. Works great.
For automated builds, I think the best tool going right now is JetBrain's Team City. The free version has all the features you'll need for most 5-10 person teams. Set up is easy, configuring new projects is painless (relatively), and most importantly, it's reliable.
For automated migrations, nothing beats PowerShell.
UppercuT uses NAnt to build and it is the insanely easy to use Build Framework.
Automated Builds as easy as (1) solution name, (2) source control path, (3) company name for most projects!
http://code.google.com/p/uppercut/
Some good explanations here: UppercuT
More information
UppercuT is a conventional automated build, which means you set up a config file and then you get a bunch of features for free. Arguably the most powerful feature is the ability to specify environment settings in ONE place and have them applied everywhere, including documentation when it builds the source.
Documentation available: https://github.com/chucknorris/uppercut/wiki
Features :
Simple setup
Simple upgrades
Custom extension points (pre, post, and replace) for each step of the build process http://uppercut.pbworks.com/CustomizeUsingExtensionPoints
Has documentation for integration w/Team City, CruiseControl.NET, and Jenkins (formerly Hudson) https://github.com/chucknorris/uppercut/tree/master/docs
Works on Linux w/Mono
Versioning DLLs based on build number and source control revisions (SVN, TFS, Git, HG)
Compile activities - F5 or Ctrl + Shift + B
Strong naming made as easy as true/false
Code Testing and Analysis
Testing
NUnit
MbUnit v2
Gallio
xUnit
NCover
NDepend
Nitriq
Mono Migration Analyzer
Obfuscation
ILMerge
Environment Templating and Building (ConfigBuilder, DocBuilder, SQLBuilder, DeploymentBuilder) https://github.com/chucknorris/uppercut/blob/master/docs/ConfigBuilder.doc?raw=true
Packaging output to prepare for deployment
Zips up output
At work we use good ol' Ant to build our Java servlets.
We used to use Visual Build from Kinook software, but recently with our new application we switched to MSBuild since it had better integration with TFS and the ability to create custom tasks.
The GNU Autotools definitely. The autoconf and automake are de-facto standard for unix systems.
I've had success using buildbot, triggered by a post-commit script on a subversion repository. This has been used for both automated builds and automated testing.
ANT for both build and deployment/installs.
Makes a great cross-platform installer.
We use Hericus Zed Builds And Bugs Management for our automated builds.
We have 4 branches of code, each with java, c++, C#, cross platform compiles and installers for 5 OS's.
Make for the builds.
Debian packages for deployments (since our production servers runs it).
TeamCity running NAnt scripts for building/packaging and PowerShell for deployment.
I've found that using NAnt, powered by TeamCity, instead of the native TeamCity runners allows us to have a much richer build process (eg. css minimiser, etc). It also means the full build/package process can be run on any developers PC instead of just the TeamCity servers making it much easier to customise and debug problems in the build process.