Deployment Projects - Do I understand them correctly?

[Jeff MacDonald]

I want to make sure I understand this properly.

In our company we have (for the sake of this discussion) 2 environments; QA and Production.

We also have 2 kinds of builds; QA Build (aka continuous integration) and Release builds.

In our world without Deployment projects, typically the QA folks could run a QA Build anytime they needed to then ask a SysAdmin to deploy it to QA server etc.

Ditto when it was time to do a release. We always accomplished this with 2 “plans” Easy.

So, I’m moving to deployment plans and I guess my question is this : how do you know when to add more tasks to one of your environments vs. when that task should instead be inside the build plan you linked to?

I might be answering my own question here, but given the environmental requirements I have, I picture this sort of configuration. ( We have over 10 almost identical projects… so i want to get this right before diving in)

1: I create a build plan for the QA builds. It should be more or less standalone where it will do these things

• source checkout
• build artifact
• apply db patches via liquibase
• copy artifact to jboss server.

2: Create a second plan (called plan-b) that makes only a release build and shares that build. Then create a deployment project with 2 environments that more or less behaves like this

• cleans the working directory for QA-environment
• takes down app from QA
• applies db patches via liquibase
• copies artifact from plan-b to the QA jboss server.
• end of QA release deploy
• begin of PROD release deploy (manual for now till we tie jira into things)
• clean working directory for PROD-environment
• take app down from PROD
• apply db patches via liquibase
• copies artifact from plan-b to PROD jboss server ( OH, can someone please answer for me how should i trigger the plan-b to actually produce the artifact ? or i guess i do that with jjira. one step to build, another step to start running the deployment project)
• end of PROD release deploy.

I think I answered my own question and created a valid scenario. It just seems like I’m re-doing the same things a few times such as copying to jboss, running liquibase tasks and it felt like I was re-doing the same work more than once.

[Jeff MacDonald · Accepted solution]

Well, i guess this turned into more of a discussion than an answer. Good work everyone! :P

[Ephraim Owen Maza]

where did you include liquibase? build or deploy plan?

[Gretchen]

I'm in the same boat. I have something like fifteen projects some with two environments some with three and each does exactly the same thing except it goes to a different server or a different path.

Now that I think about it it might be a better choice to create a single script (for each task or set of tasks as appropriate) and pass in the server name/path (or whatever the variables are) rather than duplicate each script to run them inline. That way you could create a single batch file, pass in the differing variable as an argument in each script and have lots fewer scripts to maintain.

*headdesk* (just updated twelve different projects this morning for every environment). *dies*

[Jason Monsorno]

I have Bamboo as basically a workflow manager. It will poll the repo for changes and start a workflow. Each checkout have a manifest file which tells my script/program what to build and stores the output in a folder I called Deployables which becomes my artifact. I currently have 77 plans with identical Stages, Jobs, & Tasks they only difference is the repo location because the difference between the plans is all in the repository/checkout; this also allows configuration changes to exist in branches and give some control back to developers (3 plans are protected with repo permissions on the manifest file).

My deployments are the same way, I have 2 environments on each deployment project "Functional" & "Q/A"; we haven't handed over production to Bamboo yet. The only difference between the two is the environment name and Functional has a trigger of plan success; everything is handled through variables and scripts including the Enivornment name. Our Functional "Enivornment" actually deploys to 31 different sites and our Q/A "Environment" actually deploys to 6 sites and it's all setup in scripts (and a DB for branch complexities with defaults and XR overrides). I can setup a new plan with deployment project in about a minute or I can add/delete an site from the lists in a matter of seconds. I can change the scripts to include a new deployable type of a full additional programming language and I only change it once. Variables and scripts are good, they provide modularity.

The build process should include everything that deals with transforming code into assembly, for runtime stuff like PHP this is nothing but a checkout and artifact.

The deployment should take over and include any type of environment specific changes whether it be configuration, signing, permissions, etc; ideally there is little but that is rarely the truth. Then it should actually take care of the deployment/installation.

[Gretchen]

Very fancy. I'd like to see a white paper on this with more detail. :) Sounds like wizardry.

[Jeff MacDonald]

Me writing out my question actually gave me a lot of insight into the process. Its exactly like i wrote it out. So i guess this is me answering mysefl saying "yes".. Basically make build plans create artifacts, and let deploymet projects do teh rest of the work.

However, to answer your question: don't write scripts. Instead you should duplicate your work for each slightly different environment (its a pain in the butt, but just sit down and get it over with), that way you retain the main benefit of deployment scripts which is "what jira issues are fixed where and what release versions were deployed where, by whom and when".

There is a JIRA issue with atlassian to have "clone" enabled for deployment projects, we just have to wait for it to be ready.

[Gretchen]

You always write scripts, the distinction I meant to make was instead of using a bamboo script task in your bamboo job, that uses an inline script repeated slightly differently for each project/env create a bamboo script task that calls one single script, that is repositoried of course, stored on your server in a common location (I have a scripts folder under bamboo that I use for this purpose) and called as an external script in your bamboo script task, passing in the variables for the project/env.

Both achieve the same result of being included with your bamboo build, the benefit of a single script is obviously maintainability. Both are called as tasks in your build job (or deployment job in this case) both are included in your build log (as long as you are echoing output from your external script.) You lose nothing by having an external script with a bamboo script task. You gain reuse and maintainability.

As soon as you click build in bamboo, and you retrieve your source from your repository regardless of what tasks you have in your build job any related JIRA issues are already associated to the build.

[Gretchen]

And I hear what you're saying about writing it out. Sometimes the act of documenting so that people who don't know your environment will understand the context provides clarity to the author. I do this all the time. :)