So historically, we launch our Spring application using the maven command and explicitly specifying the active profile of the application. At the root of the project, we have two .properties files:
local-application.properties, in which the settings for the local
environment are located and which are not monitored by git;
application.properties.template, which stores settings for the
dev environment.
When adding a new functionality, you may need new properties that the developer may forget to add to application.properties.template, which is why the dev environment will not start, because the person responsible for this will not know anything about these new properties.
In this regard, the question is:
Is it possible to use maven to automate a reminder to the developer to
add the necessary properties or their values to the application.properties.template file,
if such changes take place?
It may be possible to break all property values across new *.options files and then, when performing any of the maven phases (for example, verify), generate this .template file.
Or maybe there is some kind of plugin that does similar things.
Thanks!
Related
I want to apply common env variables and vm options for all my spring boot applications in Intellij.
Whenever i open a new project, the config should copy automatically.
Is there a way to do this?
Also , can i use vmoptions file for supplying my default vm arguments ?
No, you cannot use vmoptions for it, that configures the VM options for IntelliJ itself (as IntelliJ is actually written in Java).
Open the templates section in the run configurations dialog.
Scroll down until you find the run configuration you want to set the defaults for (in this case Sprint Boot).
Click on it, and anything put into the fields will be used for new configurations. Note that it is not possible to retroactively change settings for existing configurations. In this case, what you want is in the Environment dropdown to configure VM options.
Manage the configurations, hit OK, and all your new configurations will have those applied to them by default.
I am having one solution with multiple projects.
I am basically creating building blocks to build more complicated projects later on. These projects are sometimes dependent on one another, thought I am trying to keep it losely coupled.
It is sometimes necessary to debug one of the projects to test whether certain functions actually behave the way they should. ( I am going to create test projects for each individual project in the future. ).
Since they are all .lib files, everytime I make a certain project the startup project to test it, I need to switch the configuration properties to create a .exe file otherwise it wont run.
Is there a way to change the configuration of your projects based on what project is the startup project? So that I can instantly run this instead of manually changing the properties everytime I take a differnt startup project.
Your plan won't work the way you want. But I suppose you could add an extra project that can load the correct lib file and launch it. Then in the debug settings of each lib project specify that debugging will launch your extra project with the path to the lib to load as an argument.
It will require a small custom project, but will make your life easier. It'll look something like this in the debug settings:
I face a problem, common I guess.
I have a project which is store in github.
I need it to run for: production, testing and different developers.
The project uses maven profiles to set some parameters.
The project has also a spring profile: currently only DEV which initialize a DB.
The project uses external software with specfic configuration files.
I need to have the project in production but being able to serve development versions.
The question: can I use git ignore locally within developers to distribute the code and still store the files in github?
Or would you have a different solution?
The actual question is:
Can I use git ignore locally for some configuration files and still have the files on the main repository? Updated by only the production users?
One way is to store:
one different configuration file per environment
one template file
one script able to detect the current environment the git repo is cloned in, and generate the actual configuration file (which isn't versioned) used for that local environment.
That generation can be automated on checkout, with a smudge script declared as a content filter driver.
The way we have solved this is with a configuration script that pulls the server-appropriate credential file for local, staging, or production from a separate repository.
After each server pulls the appropriate file, we rename it for consistency across the different environments, and then we have our settings file which is tracked by git include the credentials file.
We are using TFS 2010. In our projects we have multiple configuration files. Each configuration file is needed for a specific build.
Example: Project XYZ includes three configuration files, lets say DEV-CONFING, QA-CONFIG and PROD-CONFIG files.
Now we want to find a way that during the build process, the build process includes the right configuration file and excludes the rest.
Example:
Build for Dev should pickup and copy only the DEV-CONFIG file (and excludes all other configuration files)
Build for QA should pickup and copy only the QA-CONFIG file (and excludes all other configuration files)
Build for production should pickup and copy only the PROD-CONFIG file (and excludes all other configuration files)
Is it possible to change the setting of individual build definition and address this issue?
What is best possible solution for this problem in VS 2010 and TFS 2010?
Please list all required steps and be precise as much as possible because I'm a newbie in TFS 2010 and have not much experience with the whole process.
The "Web Config Transformations in VS2010" addresses the problem of modifying the web.config during compile time. Some people might want the web.config to be modified at deployment time instead of compile time (like me) so that we dont have to recompile the code while moving from one environment to another, in that case you can make use of "Web Deployment Parameters"
You can read more about it at:
http://www.asp.net/mvc/tutorials/deployment/visual-studio-web-deployment/web-config-transformations
web config transformation syntax:
http://msdn.microsoft.com/en-us/library/dd465326.aspx
#user2585405 to your comment above "But all the configurations in my case are for the same mode "Release Mode". The decision should relay on the build definition. So when I use a build definition for DEV, the configuration for DEV should be automatically chosen or for QA build definition, the corresponding QA configuration should be automatically chosen."
Doesnt matter whether currently you have only one configuration. You can add how much ever configurations you want, right click the solution and select the configuration manager. Now add a new configuration say "Dev" (it can be in "Release/Debug" and also select the platform "x86, any cpu etc"). Now add another configuration for QA and PROD. Then come back to your web.config and right click and select "Add web config transformation".
Now you should be able to see the web.Dev.Config, web.QA.config etc. The root web.config will have all the common properties and the DEV/QA/Prod specific config will have only the delta changes (you have to define these entries) which are specific to that configuration (lets say connectionstring). When you compile, within the build definition you can select which configuration you want to compile (Dev, QA, prod) you dont have to keep multiple build defintion. Just one is enough! After the compilation is done, the root web.config will be replaced with the values specific to the configuration for the connectionstring part alone.
Hope this helps!
Yes this possible. You can keep configuration files in different mode for eg:
You can have configuration files in Release mode debug mode, release mode and the common configuration file used by all.
So when you build your solution in Debug mode then the debug mode configuration file will be used and when in release mode then release mode configuration file will be used.
For further clarity take example of web config when you will expand the web config tab you will see the two configuration file in different modes.
I have a lot of projects in my TeamCity server, for building and testing multiple sites. We use Selenium RC to test the sites every night, and I would like to reuse one step or configuration instead of having copies in each project.
I have looked into using Templates, but they only seem to be accessible from the project it is defined in. The same goes for properties, as I tried to put paths and some shared values in system or environment properties and using copied build steps using those shared properties.
But it all fails, as none of these methods seem to be usable across projects. How do you solve this type of issue? It must be possible somehow, right?
As per my comments for your question you can use a single template configuration build across multiple Projects.
See TeamCity documention for information on how to do this.
TeamCity has a new feature (as of 8.0) that supports global configs/parameters/env variables. 8.0 supports the new concept of project organization/nesting, and as part of that feature set all projects now inhert from the "Root" project. And on that root project you can specify a number of things, including parameters, etc. This does not appear to support build steps.
They documented the change in http://youtrack.jetbrains.com/issue/TW-11202.
--
You could achieve a "global property" by creating a dummy build configuration which has your shared properties then for all your builds which need access to the global properties you create a build dependency. When your real build configuration is called it will first call the dependent build configuration (which does nothing meaningful) then it passes the properties from the dependent config (with a dep.bt prefix instead of just the system prefix).
Depending on the logic you need in a shared build step you may be able to actually perform real logic in the dependent build (it won't be able to inherit any properties or VCS details from the "real" build).
Since this is a bit outdated, and the answers above aren't completely clear, thought I would post how I did this with TeamCity 8+.
Basically, a template can be used within the project and its children. If you move a template to the parent, it becomes available to all the siblings of the original project.
Go to the template.
Click the "Move" button (bottom-right pane).
Select a parent (or root).
Note: If the template is attached to a VCS root that is bound to the current project, you'll first have to move the VCS root to the same level to which you're trying to move the template.