Due to the requirement of the team, I need to distribute those three environments to the test team for testing purposes. But it seems TestFlight does not allow providing different environments for the same build number. How would that be handled normally?
Related
If we develop functionality in Sandbox (or Dev) and deploy using bundles to Production, once we lose the origin environment (for example - sbox refreshed), how does it affect the target org? (Production in this case) How does it affect future developments?
What is the best practice for maintaining and deploying code? Should we work in only Sandboxes? Use development org as well even though they cannot be refreshed? What should we do after sandbox refreshes?
I am managing releases for a team of 8 developers. We have three environments:
DEV - where we all make our changes
UAT - an environment for users to test changes
LIVE - live environment
We use Visual Studio 2015 and TFS 2017.
Developers make changes to files and submit them for release to UAT by emailing a list (sometimes with a changeset number). Sometimes different users will make changes to the same files but not all changes should be released.
Once tested in UAT, the changes are released to Live however sometimes a file needs to move from UAT to Live that has earlier changes in it that are not approved for Live release yet.
Please could I ask users' advice as to what the best way for managing this process should be? Unintended changes keep getting released to UAT or Live when they should remain in DEV or UAT.
Any advice would be very welcome. Thanks
Usually this kind of "the best way" question is primarily opinion-based and hard to answer.
Many good questions generate some degree of opinion based on expert
experience, but answers to this question will tend to be almost
entirely based on opinions, rather than facts, references, or specific
expertise.
Developers make changes to files and submit them for release to UAT by emailing a list (sometimes with a changeset number).
For this scenario, instead of using E-Mail to send lists, perhaps you could use this extension
This extension is a build task you can use in build steps. This task generates a markdown release notes file based on a template passed into the tool. Here is an example of release notes output:
Release notes for build SampleSolution.Master
Build Number: 20160229.3 Build started: 29/02/16 15:47:58 Source
Branch: refs/heads/master
Associated work items
Task 60 [Assigned by: Bill ] Design WP8 client Associated change
sets/commits
ID bf9be94e61f71f87cb068353f58e860b982a2b4b Added a template ID
8c3f8f9817606e48f37f8e6d25b5a212230d7a86 Start of the project
The suggestion on the comment is a way that fits your needs and your circumstances. You could create three branches stands for your three environments. And for each branch you could use branch policy(GIT) which will protect your branches and avoid unintended changes merged to UAT and Live.
Since the TFS system or any other tool is hard to judge whether some files are approved or not to release yet. It' based on your team management, you could use permissions in TFS to limit users who have access to deployment or do the release. For example only PM and team leader could handle this. Combine with work items, charts , test management, reports and other functions in TFS.
Note Team Foundation Server is a product that not only provides source code management,build, release, but also reporting, requirements management, project management (for both agile software development and waterfall teams), lab management and testing capabilities. It covers the entire application lifecycle, and enables DevOps capabilities.
Suggest you first go through the Release Management in TFS and also take a look at how to configure your release pipelines for multiple environments deployments
Is there a way to set up an Octopus lifecycle with options like this:
You can deploy to DEV, but you can't promote the build from DEV
You can deploy to QA and then promote to PROD
Have you looked into channels?
From documentation:
Which Lifecycle to use for promoting Releases: for example, feature releases may be promoted through the testing environments, while hot-fix releases may go directly to production.
I think you can create two different projects one for deployment in Dev environment and another for QA-Prod. In our octopus setup we have two branches in TFS- Dev and main branch. A code check in into dev branch does an automatic CI release deployment into INt environment. When developers do merge from dev to main branch , an automatic release gets deployed to qa which can be later promoted to prod. Of course another way can be Channel which Alex suggested.
I have started to dig in to Release Manager. Almost, if not all, examples I've seen uses a release path similar to Dev -> Test -> Production .
Say that I'm working with a web application and the organization is not using Continuous Integration in the real sense. Perhaps they are deploying to Dev many times per day, to Test a couple of times a week and to Production one time a month. (Dev and Test are then effectively different staging environments.)
So with a release path of Dev -> Test -> Production you will get a whole bunch of releases to Dev, but you don't want all Dev releases to go to Test. Therefore you would have to reject most of the releases until you are ready to deploy to Test.
What is the best practice here? Reject releases until you are ready to Test/Production? Create several Release Paths, such as:
Dev
Dev -> Test
Dev -> Test -> Production
...or something else?
In a happy DevOps/continuous delivery world, the way it works is like this:
You push bits to Dev as often as you want. The onus of picking a build to promote to QA is the developers' responsibility -- they should reject the releases they know won't be going anywhere. This is the post-deploy ("Validation") step in the Dev stage.
QA schedules the release to their environment (pre-deploy, "Approval"). They test, and give it their blessing (post-deploy, "Validation"). They reject any releases that fail QA.
Ops schedules the release to prod.
If this is an unlikely scenario because you know that none of your releases are production candidates up until a certain "blessed" build is created, then set your target stage for continuous delivery to "Dev" -- builds won't go beyond the dev environment. When you're ready to build something that's a QA and production candidate, build with a different target stage.
Our team has a full licence for the TeamCity server, as well as 7 additional agents. Another unrelated team has reached the limits of their free TeamCity licence and is eyeing our licences up.
The powers that be think it's a good idea to run both teams using the same enterprise licence, which means that we'd be hosting the TeamCity configurations on the same server, and either sharing agents or somehow assigning some agents to one team, some to another.
One concern I have is that configuring an agent to only accept certain builds is difficult - our team has hundreds of build configurations, and we create new ones all the time. To limit an agent to certain builds, you have to fully specify the whitelist. So maintaining the agents such that we have full use of some agents, and the other team has full use of theirs will be a pain. On the other hand, just using one pool of agents means now you have arguments over priority and starvation, etc.
Does anyone have any experience of this? Is it a workable solution? How do you configure agents to reserve them for a particular team? How do you configure the server so that each team only sees their own projects, build configurations and agents? Basically what we'd want is complete separation of the projects, just using the same TeamCity server and agents.
As a gut feeling it doesn't look like a good idea...
edit: As an aside, does Hudson do this better? The ivory tower architects want us to change from TeamCity to Hudson because other people are using Hudson. If I tell them this sharing TeamCity won't work, the Hudson camp will probably use it as a stick to beat us with. Joy.
Not sure what version of TeamCity you're using but the newly released TeamCity v7.0 now has a new Agent Pool feature that provides a much easier way to distribute agents. It may be of interested to you, check out the What's New section or the Agent Pools docs for more info.
I had a similar issue with our two departments starting to share the same TeamCity instance to save the expenses of additional licenses. I must admit we didn't really have any issues apart from our agents were now twice as busy.
I enabled Per-project permissions on the Global Settings page and created 2 user groups, one for 'us', and the other for 'them'. You can then configure each group's roles accordingly. If a group does not have the Project Viewer role for a project then it does not appear for them - a great way to only display necessary projects to the group; but there are plenty of other role options to use.
I have never used Hudson so can't compare unfortunately. I should really try it out but as I've always got on so well with TC I've never had a reason too.
You can make builds on run on certain agent, from the build configuration of each build in the agent requirements section, thereby limiting any build configuration to certain agents.
For example if your agent for one team is teamcity1 you can specify:
system.agent.name does not equal teamcity1
So it will never run on that agent.
That way you can at least copy build configurations and they will run on seperate agents without the fiddle agent configuration.
The other team can create a new Teamcity server, and it will have its own new set of free build configurations and agents.
We don't do this any more, but we used to split our agents into pseudo-pools so we could reserve some for compilations and others for automated tests (because automated test jobs can swamp the grid). We added a "can_run_tests" property to the test agents, and made those builds require that property as an agent condition. It worked great, and it's the sort of thing you can bake into the AMI for a set of cloud agents.
What we do now is to make the compilation and test builds require on different AMIs, which does essentially the same thing.