I have got about 30+ services. Each service has it's own repository, build and release on different environments.
Is it possible to deploy all releases for the latest build artifacts on the specified environment by single command?
There isn’t the built-in command can do it, but you can build a app (e.g. console application, PowerShell) to create release through Rest API: Create a release
You can create an overarching Release pipeline that use all the build artifacts. The downsides of this option are:
duplication of "code" between the single-component pipeline and the overarching one, mitigate using Task Groups
you do not have a simple display of what is deployed in an environment because you have to look in two places (single-component and overarching)
Related
I am managing a .net solution containing API Project, Web Project and shared assemblies.
All source code are under VSTS
And I use VSTS release for deploying project in différents environment.
Now I would like adding a version number in my web site and API site (I don't call API endpoint versioning, it's a different story).
For now the only way to do that is to Store the version information in my code and update it as any other part of the code. I would like finding a way to do that directly as part of the release process.
How are you managing the application versioning on automated release process?
Thanks.
regards,
You could store the version in the config file, such as web.config, then read the value in the code.
A simple sample:
Add <appSettings><add key="version" value="#{Release.ReleaseName}#"/></appSettings> to web.config file
Add Replace Tokens task to release
Then, the token (#{Release.ReleaseName}#) will be replaced with the value of Release.ReleaseName variable.
There are many build-in variables in release, you also can add variable to release too.
I have the following structure in my TeamCity
Commons
* Commons Release Build (takes quite long because of integration tests)
Applications
* AppA Release Build
* AppB Release Build
* AppC Release Build
All three (independent) Applications depends on the Commons-Release-Build. Currently, the single Applications trigger the Commons-Release-Build before building. But in most cases the Commons-Release-Build hasn't changed, so it is unnecessary to rebuild it.
Is it somehow possible to configure Teamcity so it triggers the commons-release-build only when changes are available?
Or is it possible to tell the commons-release-build to do nothing when no changes are available?
NOTE: Gradle is used for every build.
Thanks in advance
Guenther
Answer to my own question:
It is possible to trigger the commons-build, and say "only build when changes are available", but the better solution is to configure the commons-library not to build at all but to be triggered by the depending projects when changes are detected. So do
Disable VCS-Triggers in commons
Create VCS-Triggers in the depending projects
enable the Flag "Trigger a build on changes in snapshot dependencies" on all the VCS-Triggers of the depending projects
Time and again I am faced with the issue of having multiple environments that must be configured individually for an application that would run in all of them (e.g. QA, regional production env's, dev, staging, etc.) and I am wondering what would be the best way to organize different configurations?
Would it be in the database? Different configuration files per environment? Or maybe the same file with different sections/xml tags? How would these be then deployed? Embedded within the app? Or put manually in after installation to be modified in-place?
This question is not technology-specific - I've worked with .net and Java, web-apps and desktop apps and this issue comes up time and again. I'm looking to learn different approaches to maybe adapt a hybrid to address this.
EDIT: There's one caveat that I must point out - when configuration is part of the deployed solution, it is generally installed under root user on the host. In large organizations developers usually don't have a root access to production hosts so any changes to the configuration require a new build and deployment. Needless to say this isn't the nicest approach - especially at organizations that have a very strict release process involving multiple teams and approval levels... (sigh I know!)
Borrowed from Jez Humble and David Farley's book "Continuous Delivery (page 41)", you can:
Your build scripts can pull configuration in and incorporate it into your binaries at build time.
Your packaging software can inject configuration at packaging time, such as when creating assemblies, ears, or gems.
Your deployment scripts or installers can fetch the necessary information or ask the user for it and pass it to your application at
deployment time as part of the installation process.
Your application itself can fetch configuration at startup time or run time.
It is considered bad practice by them to inject configuration files in build and compile times, because you should be able to deploy the same binary file to every environments.
My experience was that you could bake all configuration files for every environments (except sensitive information) to your deployment file (war, jar, zip, etc). And you design your application to take in an extra parameter when starts, to pickup the right sets of configuration files (from your extracted deployment file, or from local/remote file system if they are sensitive, or from a database) during application's startup time.
The question is difficult to answer because it's somewhat vague. There is no technology-agnostic approach to configuration as far as I know. Exactly how configuration is set up will depend on the language/technology in question.
I'm not familiar with .net but with java a popular approach is to have a maven build set up with different profiles. Each profile is specific to an environment. You can then define different properties files that have environment-specific values, an example from the above link is:
environment.properties - This is the default configuration and will be packaged in the artifact by default.
environment.test.properties - This is the variant for the test environment.
environment.prod.properties - This is basically the same as the test variant and will be used in the production environment.
You can then build your project as follows:
mvn -Pprod package
I have good news and bad news.
The good news is that Config4* (of which I am the maintainer) neatly addresses this issue with its support for adaptive configuration. Basically, this is the ability for a configuration file to adapt itself to the environment (including hostname, username, environment variables, and command-line options) in which it is running. Read Chapter 2 of the "Getting Started" manual for details. Don't worry: it is a short chapter.
The bad news is that, currently, Config4* implementations exist only for C++ and Java, so your .Net applications are out of luck. And even with C++ and Java applications, it won't make pragmatic sense to retrofit Config4* into an existing application. Because of this, I'd advise trying to use Config4* only in new applications.
Despite the bad news, I think it is worth your while to read the above-mentioned chapter of the Config4* documentation, because doing so may provide you with ideas that you can adapt to fit your needs.
I'm using the Hudson promoted build plugin to try an automatic deploy if all of the maven projects are good.
My setup is similar to the following
Hudson job creates a version control tag and then triggers downstream builds of projects A and B. A triggers a downstream project Z.
I currently have the promoted builds plugin listening for success of A,B,Z. But no promotion ever happens.
I currently don't have the project triggering all 3 since there is no point in building Z before A.
Any ideas?
I think you need to configure fingerprinting so that Jenkins can keep track of which downstream build tested which upstream build.
You could try the Build Pipeline Plugin, or take some inspiration from Kohsuke's recent blog post "Doing choreography/workflow with Jenkins CLI" (login with CloudBees/Google/GitHub account required) which should give you more freedom in orchestrating your jobs.
I am currently trying to use NAnt and CruiseControl.NET to manage various aspects of my software development. Currently, NAnt handles just about everything, including replacing environment specific settings (e.g., database connection strings) based on an input target that I specify on the command line.
CruiseControl.NET is used to build the application for the default environment (dev) anytime new code is committed. I also want CruiseControl.NET to invoke a build for my additional environments test and stage, but I do not want these to be automatically invoked every time that a dev build invoked (daily) as test and stage deployments happen far less frequently. Test and stage deployments only occur when the application is ready for QA.
I can easily do this by specifying multiple projects, one for each environment. However, I already have many projects configured, one for each milestone in within my application. If I have to setup 3 projects for each milestone the CruiseControl.NET configuration can get out of hand quickly.
Here is my question:
Can I parameterize a CruiseControl.NET project configuration such that the parameters are exposed by the web interface?
Preferably (I think), I could have checkboxes for each environment (e.g., dev, test, stage) exposed in the web interface. A build would be made for each environment that is checked, whether the build was forced or automatic. It would be even better if I could default the checked state.
This feature (Dynamic Build Parameters) is currently being worked on for 1.5, and you can try it out in the nightlies. Here's a post describing the feature.
As Scott has mentioned, this isn't available, but it wouldn't take too much just to write a little template and then auto-generate the ccnet.config file given that template and a list of environments in a mail-merge type way.
Unfortunately, you can't do anything like that with CruiseControl.NET. It's a good idea, so you might want to submit it as a feature request.
This is fully supported now starting with cruisecontrol 1.5: http://cruisecontrolnet.org/projects/ccnet/wiki/Parameters