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?
Related
We are using codepipeline and codebuild with bitbucket cloud for source repositories.
We won't be releasing frequently and our releases are heavily regulated (Reviews by customers in a staging environment first) before releases etc.
We have separate branches for develop, staging, and production environment as the code pipeline doesn't support tag-based releases and feature branches will be frequently merged to the develop branch. The develop branch will be infrequently merged to staging the staging will be merged to master.
We also have a code pipeline per branch that gets triggered when there are updates in those branches.
We currently create pull requests manually from develop to staging and staging to master to trigger the respective pipelines.
I would like to understand how should the current set up be modified (minimally) to make it a true CI-CD but without a complete overhaul of the CI-CD pipeline.
How should I be making sure that the staging/production pipeline should not go through unless the develop pipeline had been triggered for the same code ( I was thinking of updating the list of versions in SSM when develop pipeline deploys so that if the version in staging/master is not found in SSM, the pipeline won't go through. Is there a better way of doing it? should I be doing this or taking a different approach?
P.S: Feature flags don't sound like a good option because we will end up with a lot of code with just feature flags since infrequent deployments. Yes, I know how trunk-based branching is what everyone keeps talking about but I don't see how is it sitting well for us with code pipeline (No tag-based triggers) and infrequent deployments to staging/prod?
It seems to me that your build and deployment process accurately reflects your release process.
I'm assuming in your company something like the following applies:
You need the production branch for hot-fixes to production. These changes need merged back to staging.
Upcoming releases (prod +1) sit in staging for a long time. You
continue to make changes on the staging branch that need merged back
to development and forward to the production branch.
Future releases (prod +2) are done on the development branch and this
code needs merged to the staging branch when ready.
You spend a lot of time managing code merges (and likely firefighting
the problems caused by code regressions)
The C in CI\CD stands for 'Continuous'. CI/CD is designed to accelerate frequent releases to production yet you explicitly say you release infrequently.
Your questions:
Closer to true CI would be to use trunk based development with short lived feature branches. Your pipeline would build a single deployment artefact and deploy this same artefact through develop, staging and production.
Feature flags or equivalent would be used to keep your code always release-able - there are no tag based triggers needed as every commit is potentially release-able.
You have indicated you understand this to some extent but don't feel it applies to your operating environment.
If you must have different pipelines running off different branches for different environments, to me this is a question of your code management process and not for code-pipeline. You should mainly handle this at source, which is in your code management tools and processes.
Your question 2 indicates to me you are not confident in this process internally at your company and are looking inside AWS to fix problems outside of AWS.
This is all a reflection of the unfortunate reality of having long lived branches for different environments.
This is exactly the scenario that that CI was developed as an antidote to but you are discounting two of the main techniques needed for the benefits of CI/CD ( Trunk based development and feature flags) and your release cycle does not support one of the main benefits, i.e frequent releases to production.
Every organisation has their own constraints and particular trade-offs and I of course don't have the full picture.
In my opinion the underlying issues in your question are a direct result of how you release and manage your code and you can't expect the benefits of CI/CD without the practices, which does mean a fundamental overhaul of how you work.
I have scoured the internet to find out what I can on this, but have come away short. I need to know two things.
Firstly, is there a best practice for how TFS & Team Build should be used in a Development > Test > Production environment? I currently have my local VS get the latest files. Then I work on them & check them in. This creates a build that then pushes the published files into a location on the test server which IIS references. This creates my test environment. I wonder then what is the best practice for deploying this to a Live environment once testing is complete?
Secondly, off the back of the previous - my web application is connected to a database. So, the test version will point to a test database. But when this is then tested and put live, I will need that process to also make sure that any data connections are changed to the live database.
I am pretty much doing all this from scratch and am learning as I go along.
I'd suggest you to look at Microsoft Release Management since it's the tool that can help you to do exactly the things you mentioned. It can also be integrated with TFS.
In general, release management is:
the process of managing, planning, scheduling and controlling a
software build through different stages and environments; including
testing and deploying software releases.
Specifically, the tool that Microsoft offers would enable you to automate the release process, from development to production, keeping track of what and how everything is done when a particular stage is reached.
There's an MSDN article, Automate deployments with Release Management, that gives a good overview:
Basically, for each release path, you can define your own stages, each one made of a workflow (the so-called deployment sequence) containing the activities you want to perform using pre-defined machines from a pool.
It's possible to insert manual interventions/approvals if necessary, and the whole thing can be triggered automatically once your build is done.
Since you are pretty much in control of the actions performed on each machine in each stage (through the use of built-in or custom actions/components) it is also certainly possible to change configuration files, for example to test different scenarios, etc..
Another image to give you and idea of how it can be done:
I Develop one website using magento. How to i Publish on server? If asp.net after publishing
codes are converted into dll . but here magento How It work? How i configure my own website?
Thanks in Advance...
There are a number of ways to do this. From simplest to most complex:
Simple zip and unpack on the server. Migrate databases with mysqldumps.
Push files with an FTP program. Preferably one with a compare viewer, such as Beyond Compare
If you utilize a QA environment or a staging site on the same box or a local server you can utilize rsync to push changes from one directory to another.
Create a source-control repository and use your production site root as a checkout of your Magento application (probably your best bet for ease of use).
Utilize source-control but deploy with a build tool such as Apache Ant.
Implement continuous integration with a tool such as Capistrano, Hudson/Jenkins, or CruiseControl
You really want to be using source control anyhow - so deploying straight from SVN/Git/Hg or another tool makes the most sense as it is easiest to manage and requires very little effort on your part. Making your repository publicly accessible can be as easy as using a free service such as GitHub or Beanstalkapp. Paid levels give you private repos or more than one user.
Continuous integration will be your best bet for rapid deployment on a site that is changing quickly and many deployments happen daily. Some comparison of tools:
http://en.wikipedia.org/wiki/Comparison_of_Continuous_Integration_Software
I hope that helps. I have deployed Magento using all of the above methods. There really is no elegant way to push databases around outside of using upgrade scripts in local modules. You can use tools like Maatkit to diff tables or in some extreme situations I've seen developers alternate between qa and production environments using Magento's built-in table prefixes.
What is the best way to have multiple configurations (dev/testing/live/etc.) for an iPad app and easily switch between them when archiving for deployment?
A common example would be to switch from the testing version of a web service URL, https://testing.mycompany.com/api, to a live version, https://customer.server.com/api.
I think it's a safe assumption that live config would never be used when developing in XCode, but it's very possible that some deployments to iPads would want to use a testing config while others obviously have live configs.
You can use different schemes, for which of your needs. There you can define what kind of build you want to make.
Are there any automated depoloyment tools out there for Magento sites?
If not does anyone have any best practices so to speak for maintaining and deploying Magento builds across local, staging and products?
This is how I've been working for the past few months and it works pretty well for me.
Install SVN on your server. Or get your host to do it. Or choose a host with SVN in place. Or git.
or
Use Springloops.
The 'trunk' is your live site.
Branches are for staging. Set up the webserver to treat these folders as subdomains.
The live database is regularly copied to branches. This refreshes the data for testing. (Consider anonymizing sales & customer data)
Each repository has it's own "app/etc/local.xml" file. Mark these with SVN:ignore so that one will not upset another.
Also SVN:ignore the "media" and "var" directories.
Each dev has a local webserver for working on. When they finish a change it is deployed to a branch ready for QA.
Nobody except the lead dev is allowed to merge branches to trunk on pain of death!
This means changes in code bubble up to the live site. Copies of the database bubble down to devs. Sometimes copies of the "media" dir are copied downwards as well. Extensions and upgrades are tested on branches too, I dislike using the Connect Manager on a live site.
Been using Git lately, so far liking it much more than SVN, this same flow could be applied to SVN as well I believe:
More details: http://nvie.com/posts/a-successful-git-branching-model/
Currently having, a local VM with a base install of Magento to setup for projects to roll out to new developers is the best approach I think. Most of us just use NetBeans inside the VM and use git pull/pushes as well as some custom build modules for deployment to all of our usual environments: local, integration, UAT, and production. Production or Integration is usually our system of record database wise.
Here is a base .gitignore file to start off with:
https://github.com/github/gitignore/blob/master/Magento.gitignore
A simple Git Deployment:
http://ryanflorence.com/simple-git-deployment/
You can try the packaged Magento that is automatically deployed with a help of Jelastic PaaS https://github.com/jelastic-jps/magento/tree/master/magento
You can get it pre-configured and installed with NGINX or LiteSpeed server and MariaDB.
After customization, you can clone the whole environment in order to get similar replicas for dev, test, stage and production. And when all needed changes are done on the cloned environment, you can just swap domains with current production and thus make the updated version available.
Or you can set up automated update process from Git/SVN.
I'm in the early stages of my first magento site. Its a big project, and my team and I have been discussing this very issue. We've seriously considered using a Git repository to maintain versioning across local, staging and live servers. Here is a good article on the subject. Its obviously focused on Wordpress, but I think the workflow would be almost identical.
And to answer your first question, I know of nothing automated.
We use SVN for very large scale projects. Almost any hosting service for your staging and product environments will be able to provide you with an SVN client to maintain sync with your repository.
Never heard of any automated deployment tools for Magento.