I am currently in the process of setting up an iOS application with Xcode bots for continuous integration on a Mac OSX Server instance. The source code is hosted on a remote git repository, so it will not be hosted on the Mac OSX Server. The application is available in several countries. In order to solve this efficiently we chose to have different build configurations depending on:
Which server environment it's going towards:
Development environment
Stage environment
Production environment
Which country is being built
I have watched the Continuous Integration with Xcode 5 & Testing in Xcode 5 WWDC 2013 videos but there are still a few things unclear.
When adding a shared scheme Xcode creates a new ApplicationName.xcscheme file.
Looking in this XML file there is a section near the end of the file:
<ArchiveAction
buildConfiguration = "Gondor Production Release"
revealArchiveInOrganizer = "YES">
</ArchiveAction>
The create a new bot dialouge doesn't seem to have an option specifing which build configuration you wish to build the application with.
Now in order to mimize git conflicts of hell what is the best approach here?
To have multiple shared schemes for each build configuration or to simply change one scheme in your feature/release branch when you are creating new bots?
The different release builds have different Bundle Identifiers, different code signing identities and different development teams.
When switching development team the project.pbxproj file removes these "CODE_SIGN_IDENTITY" strings. Is the best approach here to have a shell script checking that:
The appropriate "CODE_SIGN_IDENTITY" string exists and matches the appropriate values
The "DevelopmentTeam" string exists and matches the appropriate values
Or can I accomplish this through adding a user defined setting?
You can specify the build configuration in the build scheme under the "Archive" section. What you are wanting todo would require different schemes that you would then create a bot from.
Related
I am developing an application for the appstore which we currently have two stages for in our backend (dev & prod) and in the future plan to have three, dev, qa and prod.
To build the same via environment variables I managed already within the application in xcode and can switch between those as I want.
My challenge now is to reflect the same in appstoreconnect.
There I am actually only seeing the different versions, which is great, but I am really missing a way or process to reflect that I am using one of the stages (dev, qa, prod). Is there any way to do this?
Or do I have to create an app for every stage to be sure?
there are different approaches that you could follow. In first place I recommend using TestFlight so that you can easily manage/share/test a build with a group of people that you select.
To my mind there are a couple of approaches you could start exploring with:
creating a different target in Xcode for each environment you wanna deploy in TestFlight. To make them visually recognizable, you could bind a different app icon set to the target (Assets_Dev.xcassets, Assets_Prod.xcassets,..) via the “target memberships” ( which will
then show up the list of existing target you previously created in your Xcode project
an extension/alternative way than the previous one, (let’s assume that the only difference between the environments are just the remote endpoints used by your app to connect to your servers), would be that you make a target “non prod” into which the app has maybe a view controller or something that allows you to switch environments programmatically on the fly without having a distinct build for each of them. Such view should not be part of the acutal prod target as its purpose is merely for internal use and not for the end user (so making use of user defined keys which exist maybe only in the non prod target, and checking them with the “#if <YOUR_NON_PROD_USER_DEFINED_KEY … code to show the view for switching envs … #endif”
On TFS 2018.2, I am building a release pipeline implying the use of :
Applications configuration files
PowerShell scripts
HTML/Markdown templates (for release notes)
My applications configuration files are located on a net share for now and that works fine but I would like to version them later on.
I was about to store other files on my existing TFVC repository but I did not find a way to get them (with their directory) without adding the entire repository as a release input artifact.
I do not want to add them to my build artifacts since these files will be used for all my releases, no matter the applications I am building.
What is the recommended way
to store these files
to get them on release execution ?
I have been tempted to use the library but I feel this would be a misuse of it since it has been designed for secure files...
The correct solution to this problem is something you've already hit upon: Add them to your build artifacts. In fact, it's better than pulling them from a separate repo for a very important reason:
Your deployment scripts are going to evolve along with your application. You lose the connection between "this version of the application was deployed with these particular scripts" if the scripts come from a separate location.
You have a lot of options to control the circumstances under which they get pubilshed/downloaded:
You can use conditions on the publish artifacts tasks to control when they get published
You can use artifact filters on the release definition to control when they get downloaded as part of a release
Our team develops micro-monolith application. Which means that our applications is spitted to multiple modules like in microservice pattern but run on tomcats not containers.
We used to have linear workflow:
Environments: dev -> qa -> production
Where after each commit to dev Jenkins automatically build, run tests and deployed application to dev environment.
But lately we see that sometimes there is need to develop multiple excluding features simultaneously and we would want to have multiple dev environments.
Is there a way to allow developers to easly set and see shared properties in Jenkins? i.e. pars feature_branch_name=environment_name
Feature_branch_123=alfa
Feature_branch_124=bravo
So always on beginning of working on feature, person sets this property and later when (s)he pushes changes to repository Jenkins can automatically build and deploy given commit for previously set environment. Sharing is required because we have one build pipeline for each service and we want to be able to share this configuration across whole application.
In similar cases of sharing config between steps people recommend use of EnvInject Plugin, but I don't think this would be good solution here there would be no easy way to set parameters, the best way I could think of is by use of parameterized job, and also then people doesn't have possibility to see what parameters are currently set.
We have got legacy code base from an organization to maintain. Its huge project developed using objective C and Cocoa touch. It has 10-12 build configurations, like staging, dev, prod etc.. Other than this I see many other build configurations, which are dont seems to be in use. I just want to keep debug, release and appstore because only the base url differs. My questions are -
1)How do I clean up all these build configurations?
2)How do I compare existing build configurations and delete duplicate one?
Any help regarding this will be highly appreciable.
By Build Configuration, you mean "Targets"?
Generally we create different targets for different purposes. Like we would want the app to talk to dev server when the dev target is used and so on.
You might want to keep different targets in your app.
I'm just getting started with the team build functionality and I'm finding the sheer amount of things required to do something pretty simple a bit overwhelming. My setup at the moment is a solution with a web app, an assembly app and a test app. The web app has a PublishProfile set up which publishes via the filesystem.
I have a TFS build definition set up which currently builds the entire solution nightly and drops it onto a network share as a backup of old builds. All I want to do now is have the PublishProfile I've already setup publish the web app for me. I'm sure this is really simple but I've been playing with MSBuild commands for a full day now with no luck. Help!
Unfortunately sharing of the Publish Profile is not supported or implemented in MSBuild. The logic to publish from the profile is contained in VS itself. Fortunately the profile doesn't contain much information so there are ways to achieve what you are looking for. Our targets do not specifically support the exact same steps as followed by the publish dialog, but to achieve the same result from team build you have two choices, I will outline both here.
When you setup your Team Build definition in order to deploy you need to pass in some values for the MSBuild Arguments for the build process. See image below where I have highlighted this.
Option 1:
Pass in the following arguments:
/p:DeployOnBuild=true;DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder;PackageTempRootDir="\\sayedha-w500\BuildDrops\Publish";AutoParameterizationWebConfigConnectionStrings=false
Let me explain these parameters a bit, show you the result then explain the next option.
DeployOnBuild=true:This tells the project to execute the target(s) defined in the DeployTarget property.
DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder: This specifies the DeployTarget target.
PackageTempRootDir="\\sayedha-w500\BuildDrops\Publish": This specifies the location where the package files will be written. This is the location where the files are written before they are packaged.
AutoParameterizationWebConfigConnectionStrings=false: This tells the Web Publishing Pipeline (WPP) to not parameterize the connection strings in the web.config file. If you do not specify this then your connection string values will be replaced with placeholders like $(ReplacableToken_dummyConStr-Web.config Connection String_0)
After you do this you can kick off a build then inside of the PackageTempRootDir location you will find a PackageTmp folder and this contains the content that you are looking for.
Option 2:
So for the previous option you probably noticed that it creates a folder named PackageTmp and if you do not want that then you can use the following options instead.
/p:DeployOnBuild=true;DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder;_PackageTempDir="\\sayedha-w500\BuildDrops\Publish";AutoParameterizationWebConfigConnectionStrings=false
The difference here is that instead of PackageTempRootDir you would pass in _PackageTempDir. The reason why I don't suggest that to begin with is because MSBuild properties that start with _ signify that the property in essentially "internal" in the sense that in a future version it may mean something else or not exist at all. So use at your own risk.
Option 3
With all that said, you could just use the build to package your web. If you want to do this then use the following arguments.
/p:DeployOnBuild=true;DeployTarget=Package
When you do this in the drop folder for your build you will find the _PublishedWebsites folder as you normally would, then inside of that there will be a folder {ProjectName}_Package where {ProjectName} is the name of the project. This folder will contain the package, the .cmd file, the parameters file and a couple others. You can use these files to deploy your web.
I hope that wasn't information over load.
The ability to publish web sites, configure IIS and push schema changes for the DEV->QA->RELEASE cycle has required either custom configuration to imitate publish or custom code where IIS settings are involved.
As of Visual Studio 2013.2 Microsoft has added a third party product that manages deployment of web sites, configuration changes and database deployment with windows workflow and would be the recommended solution for automating deployment from TFS build.
More information can be found here:
http://www.visualstudio.com/en-us/explore/release-management-vs.aspx
You can use the Publish/Deploy in Visual Studio 2010.
See http://www.ewaldhofman.nl/post/2010/04/12/Auto-deployment-of-my-web-application-with-Team-Build-2010-to-add-Interactive-Testing.aspx for more information