This will be a serie of posts, because I think the subject is too long to be only one. For now, I'll just talk about my first impression on TeamFoundationService 2015.
The context I have
I usually work on enterprise environments, lot of teams and applications. Each team can be in charge of one or several applications.
If a team works only in one application then it is a big one enough to have several branches of features in progress.
If a team works only in one application then it is a big one enough to have several branches of features in progress.
If several applications by team, then we have at least one branch by application, again we deal with several branches.
In all cases, all applications handled by a team follows almost same application live cycle (ALC), same build steps, same environments to go through until Production, same tools around Continuous Integration and Deployments.
The process we follow
Every time I have the assignment of setup the Continuous Integration (CI) in a team I try to have this pipeline:
Build CI => Package Creation => Package Deployment DEV => INT => QA => UAT => PROD
Build CI => Package Creation => Package Deployment DEV => INT => QA => UAT => PROD
(simplified pipeline, sample environments)
Build: continuous integration builds, get sources, build, execute tests.
Packaging: take artifacts from latest successful CI build, create the application package and upload it to internal repository.
Deployment: take one of available packages, usually latest but no necessarily, deploy it to target environment
After QA and any acceptance tests, a package can be promoted from one environment to another, then the Deployment phase is re-executed targeting next environment in pipeline.
After QA and any acceptance tests, a package can be promoted from one environment to another, then the Deployment phase is re-executed targeting next environment in pipeline.
Meet TFS2015
TFS2012 was already in place before my arrival, with the nightmare of XAML build !! Fortunately I suffered only few weeks, then we moved to TF2015 with the new build vNext task based style, nice !
If you want a nice introduction about what VisualStudio Online (VSO) offer take a look of this Keynote by Donovam Brow, a Speaker from MS team:
TFS is the on premises version on TeamFoundationService. VSO is the cloud version.
You can find main features in both versions but they have their differences.
VSO is now called VisualStudioTeamService or VSTS.
I forgot to say that my previous 2 years I was working with TeamCity, before that with Bamboo and Jenkins(former Hudson) for about 6years. So I was very exigent about what a CI tool should provide me.
You can find main features in both versions but they have their differences.
VSO is now called VisualStudioTeamService or VSTS.
At first glance, I found all my habits on TFS, all necessary tasks to create a build, packaging and deploy, like any other CI.
Builds
For Build and Packaging, we have Builds Definitions, like jobs in Jenkins or build configuration in TeamCity. They are composed by a group of steps. Almost all necessary steps you need to build any kind of projects are available out-of-the-box in TFS and VSO.
Also, you have MarketPlace to find any other plugin you may want to add: https://marketplace.visualstudio.com/vsts
Releases
TFS also offers the Release Definitions, where you can define environments and create your pipeline from DEV to PROD.
A Release is executed based on same principle as Builds, using tasks.
Here things are not very clear still for me... I can find the same tasks available on Builds and Release configuration... Technically, you can do a deployments in a Build or any kind of build related tasks on a Release...weird...what is the purpose to have two different phases on a CI tool with same tasks ??
I have found some teams doing everything on Builds: build sources, packages creation and deployment.
Other teams are doing just build sources and tests on a Build, then package creation and deployment on Releases.
It is confusing...
Another point that creates some disorientation in our teams is that we use XLDeploy as deployment tool, it is imposed by Ops teams. The XLDeploy plugin for TFS is an all-in-one task, it is doing package creation, publish and deployment, all at the same time.
You have the possibility to do only packaging and publishing without deployment (unchecking Deploy checkbox), but it is not possible to do just deployment so we can't have a Release configured with deployment-only task with XLDeploy plugin.
We can always, of course, do a manual deployment using XLDeploy msbuild tasks or api calls, but I'm talking about what tools offers out-of-the-box.
I have found some teams doing everything on Builds: build sources, packages creation and deployment.
Other teams are doing just build sources and tests on a Build, then package creation and deployment on Releases.
It is confusing...
Another point that creates some disorientation in our teams is that we use XLDeploy as deployment tool, it is imposed by Ops teams. The XLDeploy plugin for TFS is an all-in-one task, it is doing package creation, publish and deployment, all at the same time.
You have the possibility to do only packaging and publishing without deployment (unchecking Deploy checkbox), but it is not possible to do just deployment so we can't have a Release configured with deployment-only task with XLDeploy plugin.
We can always, of course, do a manual deployment using XLDeploy msbuild tasks or api calls, but I'm talking about what tools offers out-of-the-box.
This last point is not the fault of TFS at all, it is the XLDeploy plugin approach, but it is what we have and make the experience not very satisfying for us.
Releases have some extra features, you can add approvals, tests results...you can also link a Release to a Build and create a chain with trigger conditions.
If you know TeamCity, you may think you can create build chains... but no, it is not the case. There is no chaining between Builds on TFS, just one Release after one Build, that's all.
If you know TeamCity, you may think you can create build chains... but no, it is not the case. There is no chaining between Builds on TFS, just one Release after one Build, that's all.
Reusability
TFS becomes also very difficult to maintain when things start to escalate.
When more projects , branches and builds got created we started to try to do some "refactor" on it. We wanted to Don't Repeat Yourself, we tried to reuse Build definitions, creating templates !!
Again, my bad habits with TeamCity played me a trick.
Templates on TFS are not at all the same concept we expected.
If you have a Template and you create a Build from a Template, the Build is not related anymore to the base Template. Any changes done on the Templates will not impact at all to all previous Builds created from it.
It is impossible, with current existing version of TFS/VSO, to have a base Build Configuration from where all other build derive from.
Imagine you have 10 builds with steps A, B, C and you want to add an extra step to all builds, or you want to replace step B by D.... well you need to go through all builds to apply changes 10 times... what if you have 50 builds ? what if you make a mistake on the process ?? ...time wasted.
When more projects , branches and builds got created we started to try to do some "refactor" on it. We wanted to Don't Repeat Yourself, we tried to reuse Build definitions, creating templates !!
Again, my bad habits with TeamCity played me a trick.
Templates on TFS are not at all the same concept we expected.
If you have a Template and you create a Build from a Template, the Build is not related anymore to the base Template. Any changes done on the Templates will not impact at all to all previous Builds created from it.
It is impossible, with current existing version of TFS/VSO, to have a base Build Configuration from where all other build derive from.
Imagine you have 10 builds with steps A, B, C and you want to add an extra step to all builds, or you want to replace step B by D.... well you need to go through all builds to apply changes 10 times... what if you have 50 builds ? what if you make a mistake on the process ?? ...time wasted.
Aucun commentaire:
Enregistrer un commentaire