I would like to use Travis to test two projects in one Repo.
The GIT-repository's directories currently look like this:
root
|
-- server-application
|
-- client-application
My server-application is built using the Playframework and the client-application is built for Android. In my case, it makes more sense to put both projects in one git-repository, but I still want to test the server and the Android application separately (or at least make the tests run for both projects).
The main problems I see here:
PlayFramework uses SBT and Android uses Gradle.
I dont think the server-application will use the same testing framework as the client-application.
Related
I am working on a POC where I had to containerize a part of application for eg - I need to containerize "add to cart" functionality in an e-commerce website, I see a various example https://dzone.com/articles/docker-for-devs-containerizing-your-application to containerize whole application,but how to do for a part of it where my functionalities has dependency on other code parts as well.
Any pointers will be very helpful as I am totally stuck and don't see similar query anywhere else.
Thanks
IMHO, the first thing you need to do is read more about the concept of microservices and how it works.
Basically, the idea is decouple your monolithic application into as many services as your want and deploy it separate of each other. Each of this parts will comminicate with other parts by API calls.
There are a lot of benefits of using microservices architecture, and there is no the "better way" to do this, it will depends of how your application works and how your team is engaged.
I can recommend you a couple of link about microservices:
https://medium.com/hashmapinc/the-what-why-and-how-of-a-microservices-architecture-4179579423a9
https://opensource.com/resources/what-are-microservices
https://en.wikipedia.org/wiki/Microservices
If the application is not build as microservices, it wont actually work. The POC you should be striving for is to decouple it in another seperate application.... Which I guess its much harder and larger scope of the original POC
This is how I'd do it:
create a new java/gradle module called "addToCart"
extract all functionality related to "add to cart" functionality to this single gradle, spring boot module (add relevant dependencies to build.gradle and update settings.gradle to include the new module. And use compile("module") to have dependencies on existing modules brought into your new spring-boot module (note: you can't depend on a module that is a spring boot application - this will fail because spring-boot modules are compiled differently to lib modules without the spring boot plugin).
extract any dependencies this new module has on existing code out to another new library module that can be pulled in using a gradle dependency (you're aiming to end up with a Gradle multiproject build). This is required so that existing projects/modules as well as the new one can maintain the same dependencies.
use a gradle docker plugin like https://github.com/palantir/gradle-docker OR https://github.com/bmuschko/gradle-docker-plugin to create a docker image/container for you (instructions on website). You can do this part manually also.
If you're feeling particularly adventurous you could look into building GraalVM "native images" that are container friendly. Native images start incredibly fast. Because they start so fast you don't actually need to have them running all the time, which can lower your costs. There are trade-offs though. There's a talk from Devoxx Belgium 2019 that goes into details about it here: https://youtu.be/3eoAxphAUIg?t=978
How to integrate an already created erlang OTP application with its dependencies into a single unit so that when the unit is started everything(processes) get started behind the scene?
You specify in the .app file which other applications your application depends on, like in this example. Then you build a release using reltool:create_target/2 like in this example. That function takes the definition of a release as a parameter which looks something like in this file. When Erlang VM boots the release it starts all the applications in the correct order.
There are a few third-party tools that make creating releases easier, like rebar, relx, mad, erlang.mk, or builderl (no documentation in the last one yet, used by the application that I pointed out earlier).
Currently I am trying to figure out how to use Cocoapods. Many blogs quoted that Cocoapods is the best dependency management tool at present.
However, I am also using Gradle plugin for building my application.
Now the question is, can Gradle do the same dependency management for my private files & libraries (.a files) as Cocoapods.
Long story short (Jan. 2015):
Gradle: build system + dependency management.
Cocoapods: dependency management for Xcode internal builds.
There is probably more to this (for others that want to start commenting "but Cocoapods can also.."), but for a start that summarises it.
If you are new to iOS and/or Xcode you should probably not use a mixture of Gradle and Xcode as it adds extra complexity to an already complex build environment. If you are familiar with Gradle and you also (!) have some knowledge of Xcode, then I would recommend to use Gradle. Advantage? You have full control over your builds and it saves you from messing around in endless Xcode build-config-dialogs. On top you gain access to other repositories (maybe not that interesting for you) AND you can script your builds in a cross-platform environment. I also use a non-MacOS build server (Linux+Jenkins) which is able to interpret Gradle-build scripts, which is another plus.
If you want access to a versioning system other than git, you also gain access to that... when I type the lines right here, I wonder why I ever built an app without Gradle :-). I have even more things that come to my mind, now that I think about it: mixed programming-language builds (Java/C#/objC...), unit-test integration that does not require Xcode, easy reuse of build configurations from project to project ... .
Cocoapods is pretty much tied to Xcode, since it generates Xcode project files. The problem with Xcode is that it works best when it's building the app, not some external build system. I suppose it's possible to make a Gradle plugin that uses Cocoapods repositories with Gradle's Objective-C support, but I haven't seen anything like that.
I've got an Erlang project comprising a bunch of different applications. I'm using Common Test to do some of the testing.
apps/foo/suites/foo_SUITE.erl
apps/bar/suites/bar_SUITE.erl
I'm starting to see duplication of utility code in those suites.
Where should I put my utility code so that it can be shared between the two suites?
I've considered adding another application:
apps/test_stuff
...but I can't make the CT suites depend on this without making the application under test depend on this (or can I?). I don't want to do that, because test_stuff is only needed when testing.
I have a similar problem with my eunit tests, both between applications (apps/foo/test vs. apps/bar/test), and where I'm using similar functionality between the eunit and CT tests in the same application (apps/bar/suites vs apps/bar/test). Can I use the same solution for this case as well? Or do I need to ask another question about that?
Do you think ct:require/1,2 could help you so that foo and bar SUITE would require test_stuff before it gets executed? For more information http://www.erlang.org/doc/man/ct.html#require-1
It depends on how you are packaging your final releases. For example, I use rebar for relase management. I have Cowboy fetched along with other dependencies for testing purposes, but in my reltool.config, I omit it, so it doesn't get packaged with the final product. I use rebar to run Common Test, and it's able to add Cowboy to the path without having it bundled as a lib with everything else or added as a dependency to the app I'm testing.
However, if you have another process which infers your release configuration from your dependencies, you'll have to find a way to exclude your test code when you generate a release.
Is there a way to check which Grails plugins are active and used durring application runtime?
I want to remove a plugin but I want to be absolutely sure that it is not used anymore...
Well, a brute force way would be to copy your Grails project (preferably using a source control tool like git's branching feature), remove the plugin, and make sure that:
No exceptions on a grails clean, grails compile, and grails refresh-dependencies.
All unit and integration tests pass (your team is writing those, right? ;) )
You can run the application and use it fairly normally; warning, this is the worst test, and by itself isn't sufficient, as you could end up with a BOMM.
If you're familiar with the classes in the plugin, but there are way too many Grails files to look through manually, you could use code search tools like those found in GGTS whatever IDE/text editor you're using. Even grep could be handy for finding references to those classes or some distinctly named methods.
Conversely, if the plugin is basically a black box, and your Grails app is small enough to get around, check the import statements at the top of your Controllers, Domains, and Services. If the plugin provides more client-side technology (like the jQuery plugin) check your GSPs and various items in the web-app directory (like Javascript files) for references to it.