7

Background:

3-5 developers supporting (and building new) internal applications for a non-software company. We use TFS although I don't think that matters much for my question.

I want to be able to develop a deployment pipeline and adopt continuous integration / deployment techniques.

Here's what our source tree looks like right now. We use a single TFS Team Project.

$/MAIN/src/
$/MAIN/src/ApplicationA/VSSOlution.sln
$/MAIN/src/ApplicationA/ApplicationAProject1.csproj
$/MAIN/src/ApplicationA/ApplicationAProject2.csproj
$/MAIN/src/ApplicationB/...
$/MAIN/src/ApplicationC
$/MAIN/src/SharedInfrastructureA
$/MAIN/src/SharedInfrastructureB

My Goal (a pretty typical promotion pipeline)

  1. When a code change is made to a given application I want to be able to build that application and auto-deploy that change to a DEV server.

    • I may also need to build dependencies on Shared Infrastructure Components.
    • I often also have some database scripts or changes as well

  2. If developer testing passes I want to have an manually triggered but automated deploy of that build on a STAGING server where end-users will review new functionality.

  3. Once it's approved by end users I want to a manually triggered auto-deploy to production

Question:

How can I best adopt continuous deployment techniques in a multi-application environment? A lot of the advice I see is more single-application-specific, how is that best applied to multiple applications?

  • For step 1, do I simply setup a separate Team Build for each application?

  • What's the best approach to accomplishing steps 2 and 3 of promoting latest build to new environments?

  • I've seen this work well with web apps but what about database changes

Improve this question
2
  • I won't write an answer as I don't work with or know much TFS, but I'd say any (good) CI server should be capable of polling your SCM repositories and initiates separate builds. Possibly, you might want to have some independent executor-nodes (possibly VMs if only the isolation matters, preferably physical machines if build performance will be an issue). If some of the projects have inter-dependencies, you'd need to have their builds cascade based on their hierarchy, to have the CI server publish reusable artifacts and trigger dependent projects on correct builds.
    – haylem
    Nov 9, 2012 at 1:01
  • That's absolutely true, though TFS has some built-in capabilities in this area, which is why I answered the way I did. If a third-party CI solution is acceptable, I recommend TeamCity.
    – neontapir
    Nov 13, 2012 at 16:28

3 Answers 3

Reset to default
2

I think Jenkins CI should help you to achieve what you want.

  • You can also manage dependencies between different applications using pre/post build action plugins of Jenkins.
  • Build Pipeline plugin should help you to manage the pipeline. The latest plugin allows "retry" which should help you to quickly revert back to the previous builds if you want to.
  • I've not used TFS myself, but looks like Jenkins has TFS plugin available.

About the database migrations, versioning DB should be done, in that way you can deploy a migration scripts along with the deployment.

Jenkins + Build Pipeline has been working well for me for a long time. Those were mainly small/medium complex web applications. I've tried it for small iOS and Android apps too.

Improve this answer
1
  • Thank you for the response. I'm not sure I'll use Jenkins but I appreciate the advice and I'll check it out. Also, this is the first of my questions to be answered (or responded to) by a woman so kudos to you, we need more women in this profession!
    – kingdango
    Nov 13, 2012 at 14:30
2

Many CI systems like teamcity or jenkins can be set up to monitor your version control system and kick off builds when checkins are detected. The sequence of events that is kicked off by the CI system often goes like this:

  1. If the build completes without errors, the unit tests run.
  2. If the unit tests complete without any failures, the build is deployed to staging
  3. If the staging server deploy is successful, integration tests run (at this stage people can connect to the staging server and also make sure the system is working)
  4. If the integration tests all pass, the build is copied to "good build" area
  5. A person can then deploy the "good build" at will

Regarding database changes, during the deployment process a backup of the data could be restored to the staging server and then a database migration process could be kicked off. The integration tests should catch migration problems and alert you that there were problems deploying to staging, which would disallow the copy to the "good builds" area.

Improve this answer
0
0

At a company I worked for a few years ago, we had TFS 2008 and handled deployments through build labels and a WF workflow. When a build label changed, a trigger would deploy the application to an environment. Database changes were handled through change scripts checked into a database project.

If I were doing this from scratch, I'd consider TeamCity or another dedicated CI solution rather than trying to enhance TFS. That having been said, maybe the story with TFS has improved to the point that it's viable to try it with TFS.

Improve this answer
2
  • Thank you for the advice. I'm hoping I can make this work with pure TFS and I've found some promising leads... unfortunately there is a lot of "behind the scenes" pipework code/config to make things work.
    – kingdango
    Nov 13, 2012 at 14:32
  • I concur. TeamCity is far friendlier. I've had trouble getting Jenkins working with .NET 3.5 and 4 solutions.
    – neontapir
    Nov 13, 2012 at 16:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.